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Abstract 


This  thesis  discusses  the  syntax  and  semantics  of  TAXIS,  a 
language  for  the  design  of  Interactive  Information  Systems  (IISs). 
The  thesis  als  examines  the  design  and  verification  methodologies  of 
programs  that  TAXIS  supports. 

TAXIS  offers  (relational)  database  management  facilities,  a  means 
of  specifying  semantic  integrity  constraints  and  an  exception-handling 
mechanism,  integrated  into  a  single  language  through  the  concepts  of 
class,  property  and  the  IS-A  (generalization)  relationship. 

The  formalization  of  TAXIS  involves  a  denotational  semantics  and 
an  axiomatic  semantics.  The  former  uses  simple  mathematical  concepts 
such  as  sets  and  functions  to  assign  meaning  to  TAXIS  constructs. 
The  latter  provides  an  axiomatization  of  TAXIS  in  the  spirit  of 
Hoare [69 , 71 ] .  The  two  definitions  are  then  shown  to  be  consistent  by 
proving  that  the  denotational  semantics  satisfies  (in  the  logical 
sense)  the  axiomatization. 

A  new  design  methodology  for  IISs  is  also  sketched  in  the  thesis. 
This  methodology  is  based  on  the  concept  of  stepwise  refinement 
through  specialization.  According  to  this  method,  an  IIS  is  first 
designed  at  a  fairly  high  level  of  abstraction  which  is  later  refined 
by  introducing  new  classes  that  are  specializations  of  existing  ones. 
This  design  method  is  complementary  to  traditional  design  method 
(Wirth[71])  which  are  based  on  the  concept  of  stepwise  refinement 
through  decomposition. 

Parallel  to  the  design  methodology,  a  verification  methodology  of 
IISs  is  established  in  that  the  correctness  of  an  IIS  is  shown  in  a 
stepwise  manner.  Each  refinement  of  an  IIS  can  be  specified  and  pro¬ 
ven  correct  by  using  the  results  of  the  previous  refinement.  Hence, 
the  verification  process  is  considerably  simpler. 
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1.1.  Motivation 

We  are  interested  in  the  design  of  interactive  information  sys¬ 
tems  (IISs).  Some  common  examples  of  IISs  include  credit  card  verifi¬ 
cation,  airline  and  hotel  reservation,  point-of-sale  inventory  control 
and  electronic  funds  transfer.  These  systems  are  characterized  by 
large  volumes  of  transactions  that  are  short,  very  predictable,  and 
update  intensive.  The  trend  toward  greater  cost  effectiveness  in 
future  hardware  will  make  it  economically  feasible  to  implement  more 
and  more  applications  as  IISs. 

Yet,  in  spite  of  the  considerable  structure  that  these  systems 
exhibit,  and  the  great  expense  invested  in  their  development,  very 
little  research  has  been  directed  toward  a  methodology  for  their 
design. 

Moreover,  this  kind  of  applications  programming  has  a  reputation 
among  college-trained  computer  scientists  for  being  quite  boring. 
Great  attention  must  be  paid  to  multifarious  details  and  little  con¬ 
ceptual  complexity  ever  arises.  Indeed,  it  is  partly  due  to  the 
detail  work  that  applications  programming  is  as  laborious  and  expen¬ 
sive  as  it  is.  Why  is  such  programming  so  laborious  and  yet  so  con¬ 
ceptually  easy?  In  our  opinion,  the  reason  lies  in  the  inability  of 
conventional  programming  languages  (such  as  FORTRAN,  COBOL,  and  PLl) 
to  capture  much  of  the  natural  structure  of  the  application  being 
implemented.  That  much  applications  programming  is  routine  suggests 
that  well-developed  abstractions  must  exist  in  the  mind  of  the  pro¬ 
grammer.  However,  while  the  abstractions  are  easy,  people  find  it 
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difficult  to  organize  a  lot  of  detail  without  the  aid  of  extra  mechan¬ 
isms.  This  is  especially  true  in  IIS  design,  where  transactions  are 
short  but  the  sheer  number  of  them  and  the  number  of  special  cases 
makes  the  organization  of  such  a  system  a  designer's  nightmare. 

Another  related  problem  that  we  are  interested  in  is  the 
"correctness"  of  IISs.  By  "correctness",  we  mean  that  the  IIS  is  con¬ 
sistent  with  a  logical  specification  of  what  it  is  supposed  to  do.*  It 
is  crucial  that  an  IIS  be  correct,  since  its  performance  could  deter¬ 
mine  the  success  or  failure  of  an  enterprise.  An  important  aspect  of 
correctness  involves  the  semantic  integrity  of  the  information  con¬ 
tained  in  an  IIS.  A  correct  IIS  should  guarantee  that  the  database  is 
always  in  a  valid  state.  Failure  to  do  so  can  have  disastrous  conse¬ 
quences.  If  data  processing  programs  are  seldom  "correct",  this  may 
be  due  to  the  fact  that  the  programming  languages  used  tend  to  make 
the  correctness  validation  process  extremely  troublesome  or  even 
impossible . 

We  consider  some  IIS  correctness  issues  and  propose  an  approach 
for  achieving  correctness.  The  approach,  of  course,  is  closely 
related  to  the  design  methodology  of  IIS  we  are  about  to  propose. 


L*?.*  Approach 

1.^.1.  A  Language  for  IIS  Design 

The  starting  point  of  this  research  is  the  design  of  a  language 
which  incorporates  a  specialized  set  of  abstraction  mechanisms  for  IIS 
design.  The  language  is  called  TAXIS  (pronounced  tak'  -  siss,  Greek 
noun  for  'order',  as  in  'law  and  order',  or  'class',  as  in  'university 
class')  and  its  preliminary  specification  appeared  in  (Mylopoulos, 
Bernstein  and  Wong[78a]).  TAXIS  includes  useful  concepts  from  Data- 
base  Management  and  Programming  Languages,  integrated  through  Artifi¬ 
cial  Intelligence  (AI)  techniques  from  Knowledge  Representation.  More 
specifically,  semantic  network  primitives  are  used  uniformly  to  organ¬ 
ize  modelling  concepts  such  as  relations  (Codd[70]),  transactions 
(procedures)  and  exceptions  (Goodenough[77] ,  Wasserman [77] ) .  The 
objects  constituting  a  TAXIS  program  are  classified  into  tokens  (con¬ 
stants)  which  are  instances  of  classes  (types)  which,  in  turn,  are 
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instances  of  metaclasses  (types  of  types) .  Any  object  can  have  asso¬ 
ciated  properties  which  are  either  factual  (i.e.,  specify  a  property 
of  the  object  itself),  or  definitional  (i.e.,  specify  something  about 
instances  of  the  object) .  Tokens  can  only  have  factual  properties  and 
metaclasses  only  definitional  ones.  Classes,  on  the  other  hand,  can 
have  both  factual  and  definitional  properties.  The  classes  and  metac¬ 
lasses  of  any  one  program  can  be  organized  in  terms  of  the  j[S-A  rela¬ 
tionship  into  two  hierarchies,  one  for  classes  and  one  for  metac¬ 
lasses.  The  statement  "A  IS-A  B"  means  that  every  instance  of  A  is 
also  an  instance  of  B  and  every  definitional  property  of  B  is  also  a 
definitional  property  of  A.  A  definitional  property  of  A  inherited 
from  B  can  be  refined  (specialized)  by  adding  more  structures  to  it. 
Special  rules,  which  are  called  constraints ,  exist  to  govern  the 
legality  of  such  refinements  (specializations) . 

The  framework,  based  on  tokens,  classes  and  metaclasses,  proper¬ 
ties  and  the  IS-A  relationship,  is  applied  to  all  constructs  of  TAXIS. 
The  result  is  a  programming  language  which  allows  the  creation  of  pro¬ 
grams  that  involve  a  large  number  of  data  structures  and  procedures, 
organized  into  interrelated  (IS-A)  hierarchies. 


i*^*?-*  Formal  Description  of  TAXIS 

The  uniform  treatment  of  all  TAXIS  objects  and  the  organization 
of  classes  into  IS-A  hierarchies  have  raised  some  technical  questions 
which  can  only  be  answered  within  a  formal  framework.  The  thesis 
explores  two  such  formalizations:  a  denotational  semantics  and  an 
axiomat ization  of  TAXIS.  It  is  within  one  or  the  other  formalization 
that  some  unconventional  constructs  such  as  IS-A  hierarchies  of  tran¬ 
sactions,  expressions,  statements  and  relations  are  treated. 

Moreover,  the  denotational  semantics  and  the  axiomatization  of 
TAXIS  provide  complementary  definitions  of  the  language.  In  general, 
complementary  definitions  of  a  programming  language  can  serve  several 
useful  purposes,  when  these  definitions  are  given  at  different  levels 
of  abstraction.  First,  they  can  give  additional  insight  into  the 
features  of  the  language.  Secondly,  they  may  address  themselves  to 
different  groups  of  users,  depending  on  the  features  of  the  definition 
itself  and  the  sophistication/interests  of  the  users.  Thirdly,  once 
these  definitions  have  been  proven  consistent  with  each  other,  they 
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can  be  treated  as  reliable  by  those  who  are  to  design,  implement 
and/or  use  the  language. 

The  denotational  semantics  of  TAXIS  are  defined  in  terms  of 
(semantic)  mappings  from  syntactic  constructs  to  entities,  sets  and 
functions.  The  treatment  of  IS-A  clarifies  its  relationship  to  the 
subset  relationship  of  set  theory  and,  more  importantly,  the  differ¬ 
ences  between  them. 

For  the  axiomat izat ion  of  TAXIS,  the  Floyd-Hoare  approach  was 
adopted  (Floyd[67],  Hoare [69 , 71 ] ) .  First,  an  augmented  First  Order 
Logic  is  defined  to  be  the  assertion  language  with  which  formal  pro¬ 
perties  of  TAXIS  programs  are  described.  Next,  the  effect  of  each 
execution  unit  of  TAXIS  is  described  either  by  an  axiom  or  a  rule  of 
inference  in  terms  of  primitives  of  the  form  p{s}q  where  F  and  Q  are 
formiulae  in  the  assertion  language  and  S  is  a  TAXIS  statement.  The 
meaning  of  p{s}q  is  that  if  P  is  true  before  the  execution  of  S,  then 
after  the  execution  of  S,  Q  is  true  provided  that  S  terminates. 


^  IIS  Design  Methodology 

Program  design  through  stepwise  refinement  has  been  established 
as  a  valuable  design  methodology  for  many  years  now  (Wirth[71]).  It 
must  be  pointed  out,  however,  that  refinement  is  achieved  through 
decomposition  of  a  task  into  subtasks.  Let  us  call  such  a  design 
methodology  stepwise  refinement  through  decompos i t ion . 

The  availability  of  the  IS-A  relationship  and  the  organization  of 
all  classes,  be  they  data  classes,  procedures  or  exceptions,  into  an 
IS-A  hierarchy  make  it  possible  to  define  a  new  design  methodology  for 
IISs  based  on  stepwise  ref inement  through  specialization.  According 
to  this  methodology,  an  IIS  is  first  designed  at  a  fairly  high  level 
of  abstraction  which  is  later  refined  by  introducing  new  classes  that 
are  specializations  of  given  ones.  For  example,  at  a  suitably  high 
abstraction  level,  a  student  enrollment  IIS  may  involve  only  simple 
data  classes  (such  as  student,  course) ,  transactions  (such  as  enrol¬ 
ling  a  student  to  a  course) ,  exceptions  (such  as  when  a  class  is 
filled)  and  exception  handlers  (such  as  finding  a  different  class  for 
a  student) .  Lower  abstraction  levels  may  involve  more  specialized 
data  classes  (such  as  graduate  student  and  undergraduate  course) ,  more 
specialized  transactions  (such  as  enrolling  a  graduate  student  for  an 
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undergraduate  course) ,  more  specialized  exceptions  for  the  violations 
of  the  more  detailed  constraints  enforced  in  the  transactions  (such  as 
making  sure  a  student  did  take  all  prerequisite  courses)  and  more  spe¬ 
cialized  exception  handlers  for  the  more  detailed  classification  of 
exceptions  (such  as  asking  for  an  exemption  from  the  prerequisites  of 
a  course) . 

This  design  process  is  carried  out  in  a  stepwise  fashion  until  a 
desired  level  of  detail  has  been  achieved.  Using  this  methodology, 
the  designer  can  obtain  a  complete,  usable  system  at  any  level  of 
refinement  depending  on  how  much  detail  s/he  wishes  to  incorporate  in 
the  IIS.  This  is  quite  different  from  the  structured  programming 
top-down  design  methodology,  where  a  usable  system  is  obtained  only  at 
the  end  of  the  design  process  and  the  levels  before  the  final  system 
are  regarded  as  "virtual  machines". 

The  design  methodology  through  specialization  also  facilitates 
the  extendability  of  an  IIS.  Special  rules  (IS-A  constraints)  govern 
the  refinement  of  classes,  and  hence  the  designer  is  guided  in  extend¬ 
ing  an  existing  IIS  into  a  compatible  system  which  is  guaranteed  to 
have  at  least  all  the  well-defined  properties  of  the  original  system. 

The  methodology  of  stepwise  refinement  through  specialization  can 
be  treated  as  complementary  to  stepwise  refinement  through  decomposi¬ 
tion.  For  example,  the  designer  may  well  need  the  decomposition  tech¬ 
niques  for  the  design  of  some  of  the  more  complicated  transactions. 
But  because  of  the  nature  of  IISs,  where  organization  of  details  plays 
an  overwhelmingly  important  role,  it  is  expected  that  the  specializa¬ 
tion  principle  will  be  much  more  applicable  than  its  decomposition 
counterpart.  ^ 

Design  through  specialization  has  already  been  proposed  in  (Smith 
and  Smith[77b])  for  data  classes.  In  TAXIS,  this  methodology  is 
usable  not  only  for  the  design  of  the  data  structures  but  the  design 
of  a  complete  IIS. 

l.^.£.  Correctness  of  IISs 

We  have  adopted  the  Floyd-Hoare  approach  to  verification  as  v^ell. 
An  IIS  is  correct  if  each  of  its  transactions  is  consistent  with  the 
specification  of  what  it  is  supposed  to  perform.  The  effect  on  the 
database  of  a  transaction  T  should  be  formally  described  by  two  asser- 
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tions  (written  in  the  assertion  language) ,  a  pre-condition  and  a 
post-condition  which  partially  describe  the  database  states  before  and 
after  the  execution  of  T  respectively.  A  transaction  T  is  correct 
with  respect  to  the  assertions  if  it  is  provable  in  the  axiom  system 
that  the  post-condition  is  true  after  the  execution  of  T,  given  that 
the  pre-condition  is  true  before  the  execution  of  T. 

We  next  examine  the  relationship  between  our  design  methodology 
of  IISs  and  their  verification  of  correctness.  The  premise  is  that  a 
good  design  methodology  should  facilitate  the  verification  of  the 
final  system.  Parallel  to  the  design  process,  the  correctness  of  an 
IIS  is  shown  in  a  stepwise  fashion.  Each  refinement  of  an  IIS  can  be 
specified  and  proven  correct  by  using  the  results  of  the  previous 
refinement,  hence  the  verification  process  is  considerably  simpler. 

The  problem  of  semantic  integrity  of  the  information  of  an  IIS  is 
approached  from  two  directions.  Firstly,  TAXIS  is  designed  with 
powerful  constructs  to  express  semantic  constraints,  both  declara- 
tively  (through  the  data  modelling  constructs)  and  procedurally 
(through  the  association  of  operations  to  data).  Also,  TAXIS  is 
equipped  with  an  exception  handling  mechanism  which  allows  the 
designer  to  declare  exception  situations  and  specify  how  to  handle  the 
exceptions . 

An  IIS  can  be  formally  shown  never  to  violate  the  stated  semantic 
integrity  constraints.  The  idea  is  that,  for  each  transaction  in  the 
IIS,  we  must  show  that  if  the  information  in  the  IIS  satisfies  all  of 
the  semantic  integrity  constraints  before  execution  of  the  transac¬ 
tion,  then  after  the  execution  of  the  transaction,  the  information  of 
the  IIS  again  should  be  correct.  So  semantic  integrity  of  an  IIS  is 
guaranteed  by  treating  all  the  constraints  as  part  of  the  specifica¬ 
tion  of  each  transaction  of  the  IIS.  Again,  we  expect  that  the  design 

the 
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1.3^.  Related  Work 

This  section  surveys  those  research  areas  relevant  to  this 
thesis . 

In  AI ,  semantic  networks  have  received  considerable  attention  as 
information  structures  for  representing  and  organizing  knowledge  in 
knowledge-based  computer  systems.  A  simple  semantic  network  is  a 
labelled  directed  graph,  where  the  nodes  represent  objects  or  events, 
and  edges  represent  relationships  between  the  objects  or  events.  From 
these  primitive  concepts,  complex  situations  and  concepts  can  be 
represented.  Semantic  networks  offer  structuring  primitives  such  as 
the  INSTANCE-OF  relationship,  the  IS-A  relationship,  the  PART-OF  rela¬ 
tionship  (Mylopoulos  and  Levesque [78] )  and  partitions  (Hendr ix [75] ) 
through  which  one  can  define  complex,  highly  structured  knowledge¬ 
bases.  The  meaning  of  a  semantic  network  knowledge-base  has  been 
given  in  terms  of  First  Order  Logic  by  some  researchers  (Schubert [ 76] , 
Shapiro[75]  etc.)  who  view  a  semantic  network  as  a  convenient  data 
structure  for  representing  logical  formulas,  and  in  terms  of  pro¬ 
cedures  by  others  (Abrial[74],  Levesque [77] ) .  An  excellent  survey  of 
the  history  and  issues  associated  with  semantic  networks  appears  in 
Brachman [79] .  The  research  described  in  this  thesis  was  influenced  by 
semantic  network  modelling  techniques,  particularly  those  described  in 
Abrial[74],  Levesque[77]  and  Levesque  and  Mylopoulos [79] . 

In  Database  Management,  the  relational  theory  of  databases 
(Codd[70])  has  become  a  major  focus  of  research  mainly  because  of  its 
simplicity,  its  high  degree  of  data  independence,  the  ease  with  which 
database  problems  can  be  formalized  in  precise  mathematical  terms,  and 
the  small  yet  powerful  languages  that  can  be  developed  around  it. 
TAXIS  includes  constructs  similar  to  ones  found  in  a  subset  of  the 
query  language  QUEL  of  the  relational  database  system  INGRES  (Held  et 
al.  [75])  through  which  the  database  management  aspects  of  an  IIS  are 
to  be  defined. 

The  use  of  IS-A  for  the  structuring  of  a  database  has  already 
been  suggested  by  other  authors  (Roussopoulos [ 76] ,  Smith  and 
Smith [77a , b] ) .  This  proposal  is  adopted  and  extended  in  TAXIS  to 
apply  not  only  to  the  data  structures  used  by  the  IIS  (i.e.,  rela¬ 
tions,  domains,  aggregates  etc.)  but  also  to  procedures,  exceptions, 
expressions  and  statements  constituting  a  TAXIS  program. 
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Recently,  several  "semantic"  data  models  have  been  proposed  which 
contain  primitives  intended  to  facilitate  the  modelling  of  real  world 
systems.  Among  these  data  models,  we  note  Abrial[74],  Senko[73], 
Chen[76] ,  Tsichr itz is [75] ,  Roussopoulos [76]  and  Smith  and 
Smith [77a, b] .  Kerschberg  et  al. [76]  surveys  these  and  other  data 
models.  Moreover,  in  Wong  and  Mylopoulos [77] ,  the  data  modelling 
primitives  from  both  Database  Management  and  AI  are  surveyed  and  com¬ 
pared  . 

The  exception  handling  mechanism  proposed  in  this  thesis  is  simi¬ 
lar  to  the  procedural  treatment  of  exception  handling  proposed  by 
Wasserman [77] .  In  his  proposal,  all  exceptions  have  to  be  declared, 
and  when  an  exception  is  raised  by  a  module,  it  is  up  to  the  caller  of 
the  module  to  specify  a  handler,  which  is  a  procedure,  to  handle  the 
exception.  This  idea  is  incorporated  into  TAXIS  by  integrating  it 
into  the  framework  of  classes,  instances,  properties  and  the  IS-A 
relationships.  The  control  structure  of  Wasserman' s  exception  han¬ 
dling  proposal  has  been  simplified  to  allow  for  cleaner  treatment  and 
the  resulting  mechanism  is  similar  to  that  proposed  in  Levin[77]. 

Another  relevant  research  area  is  the  inductive  assertion  methods 
of  verification  of  programs.  This  approach  to  program  verification 
was  pioneered  by  Floyd [67].  The  method  requires  that  assertions  be 
attached  to  some  of  the  connections  in  the  flowchart  of  a  program  and 
then  to  prove  that  each  assertion  is  true  every  time  the  flow  of  con¬ 
trol  passes  through  the  connection  it  is  attached  to.  Hoare  formal¬ 
izes  the  notion  of  inductive  assertion  through  the  use  of  axioms  and 
rules  of  inference  for  reasoning  about  the  correctness  of  computer 
programs  (Hoare [69 , 71 ] ) .  A  small  language  is  defined  in  Hoare[69]  in 
terms  of  the  p{s}q  notation,  where  simple  statements  such  as  assign¬ 
ment  are  defined  as  axioms  and  structured  statements  such  as  IF,  WHILE 
are  given  rules  of  inference.  A  program  can  be  proven  correct  in  the 
same  way  one  proves  a  theorem  in  a  deductive  system.  At  least  two 
high  level  languages  have  been  axiomatized  using  a  similar  approach 
Pascal  (Wirth[70],  Hoare  and  Wirth[74]),  and  Euclid  (Lampson  et 
al. [77]  ,  London  et  al.[78]). 

Another  method  of  describing  the  meaning  of  programming  languages 
is  by  so-called  denotational  semantics.  The  work  of  Scott  on 
mathematical  semantics  (Tennent [75]  ,  Donahue[75])  and,  of  course,  Tar- 
skian  semantics  (Mendelson [64] )  offer  useful  insight  into  the  problem 
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of  defining  a  denotational  semantics  for  a  formal  language. 

The  proposal  of  complementary  definitions  of  programming 
languages  was  first  made  in  Hoare  and  Lauer[743  where  they  describe  a 
subset  of  Algol  through  four  different  definitions.  Each  subsequent 
definition  is  shown  to  be  consistent  to  the  definition  before  it. 
Cook[75J  gives  two  semantic  descriptions  of  essentially  the  same  sub¬ 
set  of  Hoare  and  Lauer,  and  shows  the  first  definition,  an  axiomatiza- 
tion  based  on  the  Floyd-Hoare  approach,  to  be  sound  and  in  a  certain 
sense  complete  with  respect  to  a  second  operational  definition  where 
the  meaning  of  a  program  is  described  by  giving  the  sequence  of  states 
occurring  in  an  interpretive  model  when  the  program  is  executed. 
Donahue[75]  gives  a  denotational  semantics  (based  on  Scott's  work)  and 
an  axiomatic  semantics  to  a  subset  of  Pascal  and  shows  the  latter  to 
be  consistent  with  the  former. 


i. * i *  Thesis  Outline 

Chapter  Two  describes  TAXIS  informally.  It  is  a  revised  version 
of  Mylopoulos,  Bernstein  and  Wong [78b].  Chapter  Three  defines  the 
syntax  and  informal  semantics  of  TAXIS.  The  syntax  is  defined  using  a 
modified  BNF  notation.  Two  important  constructs  of  TAXIS  are  not 
dealt  with  in  the  chapters  to  follow  in  order  to  keep  the  thesis  to  a 
reasonable  length.  They  are  recursion  and  the  concept  of  'unknown'  in 
the  database.  The  latter  is  treated  separately  in  Mylopoulos  and 
Wong[80].  The  treatment  of  recursive  procedure  has  received  a  lot  of 
attention  in  programming  languages,  and  we  chose  to  put  more  emphasis 
on  the  constructs  that  are  not  found  in  conventional  languages  rather 
than  complicate  our  framework  to  accomodate  yet  another  treatment  of 
recursion.  In  Chapter  Four,  a  detailed  example  is  presented  to  illus¬ 
trate  our  IIS  design  methodology.  Chapter  Five  provides  a  denota¬ 
tional  model  of  TAXIS  in  terms  of  sets,  functions  and  set  operators. 
It  is  an  expanded  version  of  an  early  draft  by  John  Mylopoulos  on  the 
semantics  of  TAXIS.  Chapter  Six  presents  a  formal  definition  of  TAXIS 
in  terms  of  axioms  and  rules  of  inference.  Chapter  Seven  presents  a 
proof  of  the  soundness  of  the  axiom  system  with  respect  to  the  denota¬ 
tional  model.  It  is  acknowledged  that  some  rules  and  their  soundness 
arguments  were  derived  together  by  Alex  Borgida  and  myself.  The  most 
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recent  version  of  these  rules  appears  in  Borgida  and  Wong [81].  In 
Chapter  Eight,  the  specification  and  verification  methods  for  IISs  are 
illustrated  by  showing  the  IIS  design  presented  in  Chapter  Four  to  be 
in  some  sense  correct.  The  proof  of  correctness  methodology  is  based 
on  the  assumption  that  all  TAXIS  objects  obey  certain  'well-formed' 
conditions  we  call  semantic  constraints .  Chapter  Nine  concludes  the 
thesis  and  discusses  future  research  topics. 
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2.1.  Introduction 


In  order  to  help  the  reader  visualize  the  approach  we  are  taking 
to  IIS  design,  we  present  in  this  section  an  informal  description  of 
TAXIS  which  includes  several  examples. 

Section  2 .2  discusses  the  basic  entities  that  constitute  a  TAXIS 
program.  Section  2.3  describes  the  IS-A  hierarchy  as  an  organiza¬ 
tional  principle  (abstraction  mechanism)  for  the  classes  constituting 
a  program.  In  Section  2.4  we  present  more  details  about  the  different 
categories  of  classes. 


Classes ,  Tokens  and  Properties 
^.^.1 .  Classes  and  Tokens 

A  class  is  a  collection  of  objects  sharing  common  properties. 
The  objects  constituting  a  class  are  its  instances  .  It  may  be  help¬ 
ful  for  the  reader  to  compare  TAXIS  classes  with  SIMULA  classes  or 
programming  language  types  as  points  of  reference. 

Some  sample  classes  are  PERSON,  whose  instances  are  relation 
tuples  for  persons,  PERSON-NAME,  whose  instances  are  strings  that  can 
serve  as  proper  names,  and  INTEGER,  whose  instances  are  integers. 

Instances  of  classes  are  called  tokens .  For  example,  john-smith, 
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an  instance  of  PERSON,  ' SMITH, JOHN, B. ' ,  an  instance  of  PERSON-NAME, 
and  4,  an  instance  of  INTEGER  are  tokens.  Classes  are  instances  of 
metaclasses .  TAXIS  users  can  define  new  metaclasses. 

The  major  built-in  metaclasses  in  TAXIS  include 

-  finitely-defined  classes  -  similar  to  Pascal  scalar  types.  e.g., 

COLOR. 

"  f orni-def ined  classes  -  classes  with  tokens  satisfying  certain  string 
patterns,  e.g.,  PHONEY-VALUE. 

-  test-defined  Classes  -  data  classes  defined  through  a  predicate, 

e.g.,  POSITIVE-NUMBER  defined  through  P(x)  =def  x  =>  0. 

-  aggregates  -  similar  to  those  of  Pascal  record  types,  e.g., 

ADDRESS- VALUE,  DATE. 

-  relations  -  similar  to  Codd's  relations,  e.g.,  AIRCRAFT,  FLIGHT, 

PERSON,  AIRPORT. 

transactions  -  essentially  procedures,  e.g.,  RESERVE-A-SEAT, 
CANCEL- A-FLIGHT,  FIND- ALTERNATIVE. 

-  expressions  -  basic  units  of  statements,  e.g.,  f.seats-left  >  0. 

-  statements  -  basic  units  of  execution  in  TAXIS,  e.g.,  x  <-  1. 

-  exceptions  -  they  signal  an  abnormal  situation  that  may  arise  during 

the  execution  of  a  TAXIS  program,  e.g.,  NO-SEATS-LEFT, 
CANCELLED-FLIGHT . 

2,2,2.  Properties 

Classes  and  tokens  have  properties  through  which  they  can  be 
related  to  other  classes  and  tokens.  Some  of  the  properties  that  may 
be  associated  with  PERSON  represent  the  following  information 

"each  person  has  a  name,  an  address,  an  age  and  a  phone  number" 
"each  person  name  consists  of  a  first  and  last  name  and  possibly 
a  middle  initial" 

For  tokens,  properties  represent  specific  facts  rather  than 
abstract  rules  such  as  those  presented  above.  Thus,  john-smith  will 
have  properties  expressing  facts  such  as 

" john-smi th ' s  name  is  ' SMITH, JOHN,B' ,  his  address  is  38  Boston 
Dr,  Toronto,  his  age  is  32,  and  his  phone  number  is  762-4377" 

Properties  are  triples  consisting  of  one  or  more  subjects ,  an 
attribute  (or  property  name) ,  and  a  property  value  (p-value) .  For 
example,  PERSON  may  have  properties  (i.e.,  may  be  the  subject  of 
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properties)  whose  attributes  are  the  identifiers  "name”,  "address"  and 
"phone*",  and  whose  p-values  are  (respectively)  the  classes  PERSON- 
NAME,  ADDRESS-VALUE,  and  PHONE*-VALUE.  Properties  can  be  represented 
in  terms  of  a  directed  graph  (fig.  2.1).  The  same  applies  for  proper¬ 
ties  of  tokens  (fig.  2.2). 

The  properties  we  have  seen  so  far  allow  aggregation  of  data 
objects  and  are  similar  to  relational  attributes  or  record  fields. 
Not  all  TAXIS  properties  have  this  flavor,  however.  In  general,  any 
information  one  wishes  to  associate  with  an  object  has  to  be 
represented  in  terms  of  properties.  TAXIS  uses  property  categories  to 
distinguish  between  properties  used  to  express  different  aspects  of  an 
object's  structure  and/or  behavior. 

In  general,  then,  properties  of  a  class  provide  information  about 
the  structure  and/or  behavior  of  its  instances,  whereas  properties  of 
a  token  describe  the  token  itself.  This  distinction  was  already  made 
in  the  graphical  representations  of  the  properties  of  PERSON  and 
john-smith,  the  properties  of  the  latter  being  represented  by  flat 
arrow  heads.  We  call  the  properties  of  classes  definitional  and  those 
of  tokens  factual . 

Some  properties  may  have  more  than  one  subject.  Consider,  for 
example,  the  representation  of  the  information 

"the  transaction  RESERVE-SEAT  reserves  seats  for  persons  in 
flights". 

Treating  this  as  information  about  the  behavior  of  instances  of  the 
classes  PERSON  and  FLIGHT  we  might  create  the  properties  as  in  fig. 
2.4.  The  problem  with  the  representation  is  that  it  treats  the  two 
properties  as  independent  when,  in  fact,  they  are  not.  In  TAXIS  this 
situation  is  represented  in  terms  of  one  complex  property  with  two 
subjects  (fig.  2.5). 

Thus,  properties  can  be  compared  along  different  dimensions. 
Depending  on  the  kind  of  information  they  represent  about  their 
subjects (s)  and  how  this  will  be  used  by  a  TAXIS  program,  they  are 
classified  into  property  categories .  Depending  on  whether  they 
represent  information  about  their  subject(s)  or  instances  of  their 
subjects,  they  are  treated  as  factual  properties  or  definitional  pro¬ 
perties  .  Finally,  depending  on  their  number  of  subjects,  they  are 
simple ,  if  they  have  a  single  subject,  or  complex  otherwise. 
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If  class  C  has  a  simple  (definitional)  property  with  attribute  p, 
the  TAXIS  expression  C..p  returns  p's  p-value.  Similarly,  if  Cl, 
C2,...,  Cn  are  subjects  of  a  property  with  attribute  p, 
(Cl ,C2 , . . . ,Cn) . . p  evaluates  to  the  p-value  of  p. 

Turning  to  facts,  let  C  be  a  class  with  property  p  and  let  c  be 
an  instance  of  C.  Then 

(i)  If  C..p  is  a  data  class,  i.e.,  a  finitely-defined,  form- 
defined  class,  aggregate,  relation  or  exception,  then  c.p  evaluates  to 
an  instance  of  C..p. 

(ii)  If  C..p  is  a  transaction,  then  c.p  evaluates  to  the  object 
returned  by  the  application  of  the  transaction  C..p  to  argument  c. 

The  same  two  cases  apply  to  a  complex  property  p  with  subjects  Cl, 
C2,...,Cn.  If  cl,  c2,.,.,  cn  are  instances  of  Cl,  C2,...,  Cn  respec¬ 
tively,  then  (cl ,c2 , . . . ,cn) .p  evaluates  to  an  instance  of 
(Cl ,C2 , . . . ,Cn) . . p  or  the  result  of  applying  the  transaction 
(Cl . C2 , . . . ,Cn) . . p  to  arguments  cl,  c2,...,cn. 


2,2,^.  Examples 

Classes  are  defined  by  specifying  their  name  (we  will  use  iden¬ 
tifiers  in  capital  letters  for  this)  and  their  simple  properties 
grouped  into  property  categories.  For  example,  the  relation  class 
PERSON  can  be  defined  by 


relation  PERSON  with 
keys 

per son-ident :  (  name,  address 

attrs 


name : 
address : 
r-attrs 
age : 
phone# : 
status : 

end 


PERSON-NAME: 
ADDRESS- VALUE; 

AGE- VALUE; 
PHONE-VALUE: 
STATUS- IN-CANADA 


A  relation  class  can  have  properties  from  the  categories  key  ,  attrs 
and  r-attrs  (relational  attributes) .  The  single  key  property  of  PER¬ 
SON  is  named  "per son-ident"  and  it  specifies  that  name  and  address 
form  the  key  of  PERSON  instances.  The  other  properties  of  PERSON  have 
as  values  classes  that  have  been  predefined  and  are  named  (respec¬ 
tively)  PERSON-NAME,  ADDRESS- VALUE ,  AGE-VALUE,  PHONE#-VALUE  and 
STATUS- IN-CANADA. 

Let  us  next  see  how  some  of  these  classes  might  be  defined: 
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aggregate  ADDRESS-VALUE  with 
attrs 


no: 

street: 

city; 

province 

country: 

end 


POSITIVE-INTEGER 
STREET- NAME; 
CITY; 

PROVINCE; 

COUNTRY ; 


Aggregate  classes,  unlike  their  cousins  relations,  only  have  attribute 
properties,  through  which  one  can  access  the  internal  structure  of 
their  instances.  The  attribute  properties  of  aggregate  instances  can 
not  be  modified.  Similarly, 


PHONE*- VALUE  :=  { 

1  1 

}  @  REPEAT (DIGIT, 3)  @  {I 

1  ')  '  1  1 

@  REPI 

2AT(DIGI 

defines  PHONE*- VALUE  to  be  a  form-defined  class,  whose  instances  obey 
the  format  (ddd) ddddddd ,  where  d  stands  for  a  digit.  The  symbol 
associates  the  identifier  on  the  left  hand  side  to  the  simple  class 
defined  on  the  right.  Constants  are  quoted  (e.g.,  '(',  ')')  while  the 
matchfix  operators  {|  |}  create  a  class  whose  instances  are  their 

operands.  The  infix  operator  @  takes  two  (string)  classes  as  operands 
and  constructs  a  new  class  whose  instances  are  concatenations  of 
objects  from  the  two  classes. 

Transactions  are  classes  too.  Thus,  the  transaction  RESERVE-SEAT 
may  be  defined  as  follows: 


transaction  RESERVE-SEAT  with 

?arams  reserve-seat:  (p,  f,  d) ; 
ocal  s 

x:  RESERVATION; 
p:  PERSON; 
f:  FLIGHT; 
d :  DATE ; 
prereqs 

seats-left?:  f.seats-left  >0; 

actions 

make-reservation:  insert-object  x  in  RESERVATION  with 

person:p,  f It# : f . flight# ,  date:d; 
decrement-seat:  f.seats-lert  <-  f.seats-left  -  1; 

end 


Transactions  can  have  properties  in  categories  params,  locals, 
prereqs,  actions  and  results.  Each  transaction  class  has  exactly  one 
params  property,  with  subjects  the  p-values  of  parameters  and  p-value 
the  transaction  itself.  In  the  case  of  RESERVE-SEAT  the  params  pro¬ 
perty  has  subjects  PERSON,  FLIGHT,  DATE  and  attribute  reserve-seat  and 
p-value  RESERVE-SEAT.  Local  properties  define  local  variables  of  a 
transaction.  The  prerequisite  and  result  properties  of  a  transaction 
define  the  preconditions  and  post-conditions  of  the  transaction.  The 
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action  properties  have  values  statements  which  constitutes  the  body  of 
the  transaction.  Execution  of  a  transaction  instance  involves  evalua¬ 
tion  of  each  prerequisite  expression  (pre-condition)  and  a  check  that 
the  returned  value  is  true.  If  not,  execution  of  the  transaction  is 
suspended  and  an  exception  instance  is  raised  (for  the  example,  no 
exception  is  mentioned  to  keep  the  example  simple;  we  will  return  to 
this  point  later).  If  all  prerequisites  return  true,  all  actions  of 
the  transaction  are  executed  in  order.  Finally,  all  results  (post¬ 
conditions)  are  evaluated  and  they  too  must  evaluate  to  true  or  else 
an  exception  is  raised. 

Returning  to  RESERVE-SEAT,  its  prerequisite  checks  that  there  are 
seats  left  for  the  flight  where  the  seat  is  to  be  reserved.  Note  that 
f  has  as  value  an  instance  of  the  relation  FLIGHT,  i.e.,  is  a  pointer 
to  a  tuple  of  the  relation  FLIGHT.  It  follows  that  the  expression 
f.seats-left  involves  a  retrieval  from  the  database.  The  action 
"make-reservation"  creates  an  instance  of  the  relation  RESERVATION  in 
terms  of  the  flight#  attribute  of  the  flight  tuple,  the  person  tuple 
p,  and  the  DATE  aggregate  instance.  The  last  action  decrements  the 
"seats-left"  r-attribute  of  f. 

When  the  p-value  of  a  definitional  property  (Cl,  ...Cn)..p  is  a 
transaction,  say  T,  the  meaning  of  the  property  changes  in  that  T 
specifies  not  the  type  of  p-values  of  factual  properties  induced  by 
(Cl,  ...,Cn)..p,  but  rather  an  algorithm  for  getting  them.  For  exam¬ 
ple,  suppose  the  property 

PERSON. .birthday  =  COMPUTE-BIRTHDAY 
is  added  to  the  definition  of  PERSON  where 

transaction  COMPUTE-BIRTHDAY  with 
par^ms  (p; birthday) 

actions 

compute:  birthday  <-  this  year  -  p.age; 

end 

and  "this  year"  is  an  identifier  that  denotes  the  current  year. 
Clearly,  to  every  particular  person  this  property  associates  not  an 
instance  of  COMPUTE-BIRTHDAY  but  rather  a  token  returned  by  the  p- 
value  of  the  transaction. 

This  convention  of  treating  transactions  as  means  for  obtaining 
p-values  rather  then  as  types  of  p-values  is  consistent  with  the 
SIMULA  class  concept.  Thus,  in  TAXIS 
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p. birthday  =  COMPUTE-BIRTHDAY (p ,  birthday) 
where  p  is  an  instance  of  PERSON  and  birthday  is  a  variable  to  save 
the  result. 

Finally,  we  define  the  relation  FLIGHT  which  is  used  by  the  tran¬ 
saction  RESERVE-SEAT. 

relation  FLIGHT  with 
keys 

f light-ident : 
attrs 

flight#: 
r-attrs 

departure: 
destination : 
aircraft : 
time : 

seats-lef t : 

end 

The  domain  class  {|  1::999  |} 
and  999. 

l.*2*  The  IS-A  Hierarchy 

2.2*1.  Preliminaries 

We  envision  a  TAXIS  program  as  a  large  collection  of  classes  and 
tokens  interconnected  through  their  properties.  Perhaps  the  most 
important  feature  of  TAXIS  is  the  facility  it  provides  for  organizing 
the  collection  of  classes  into  a  hierarchy  (taxonomy). 

A  class,  A,  is  placed  below  another  class,  B,  in  the  hierarchy  if 
every  instance  of  A  is  also  an  instance  of  B.  If  A  is  below  B  we 
write  A  IS-A  B  and  say  "A  is  a  B”;  the  class  hierarchy  de'fined  by  IS-A 
is  called  the  IS-A  hierarchy.  For  example,  ADULT  IS-A  PERSON,  CHILD 
IS-A  PERSON  since  clearly  every  child  and  every  adult  is  a  person. 

If  A  IS-A  B,  every  property  of  B  is  also  a  property  of  A,  unless 
it  is  redefined  in  A.  Moreover,  A  can  have  additional  properties  B 
does  not  have  at  all.  For  example,  the  class  ADULT  inherits  the 
"name",  "address",  and  "phone"  properties  of  PERSON,  but  redefines  its 
"age"  property  by  restricting  "age"  values  to  instances  of  the  class 
OVER-18.  Similar  remarks  apply  for  CHILD  which,  in  addition,  has  the 
"guardian"  property  that  PERSON  does  not  have.  In  defining  the 
classes  ADULT  and  CHILD,  one  need  not  mention  the  properties  these 


(flight#) ; 
{|  1::999 


1; 


city :CITY, count ry : COUNTRY 
^  city : CITY, country : COUNTRY 
..iRCRAFT-TYPE; 

TIME; 

NONNEGATIVE- INTEGER ; 


11 


1  ? 


has  as  instances  the  integers  between  1 
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classes  share  with  PERSON: 


relation  ADULT  is-a  PERSON  with 


r-attrs 

age:  OVER-18; 

end 


relation  CHILD  is-a  PERSON  with 
r-attrs 


end 


age : 

guardian 


UNDER- 18 
ADULT; 


Properties  cannot  be  redefined  arbitrarily.  For  example,  redefinition 
of  the  "age"  property  only  makes  sense  if  UNDER-18  IS-A  AGE-VALUE,  and 
OVER- 18  IS-A  AGE-VALUE. 

The  relationship  IS-A  between  classes  is  a  partial  order  and  the 
most  important  property  it  has  is  the  Structural  IS-A  Constraint : 

Structural  IS-A  Constraint :  If  A  IS-A  B  and  B  has  simple  property 
p,  then  A  too  has  property  p  and  A..p  IS-A  B..p.  Similarly,  if  B  is 
one  of  the  subjects  of  complex  property  p,  i.e.,  p  has  subjects  Cl, 
C2,  ...,  Cn  and  Ci  =  B,  then  A  too  is  one  of  the  subjects  of  complex 

property  p  and  (Cl ,C2 , . . . , A, . . . ,Cn) . .p  IS-A  (C1,C2 , . . . ,B, . . . ,Cn) . .p. 

The  IS-A  hierarchy  need  not  be  a  tree  (e.g.,  MALE-STUDENT  IS-A 
MALE,  MALE-STUDENT  IS-A  STUDENT)  nor  need  it  be  the  case  that  if  B1 
IS-A  A  and  B2  IS-A  A,  then  the  collection  of  instances  of  Bl  and  B2 
are  mutually  exclusive. 

^.3^.^.  More  on  Seat  Reservations 

We  return  to  the  world  of  persons,  flights  and  seat  reservations 
to  illustrate  the  use  of  the  IS-A  hierarchy.  First,  let  us  define  two 
specializations  of  FLIGHT  called  INTERNATIONAL-FLIGHT  and  FLIGHT- 
W I TH IN-CANADA: 

relation  INTERNATIONAL-FLIGHT  is-a  FLIGHT  with 
r-attrs  , ,  , , 

flight#:  {  |  500  :  : 999 | } ; 

end 

relation  FLIGHT-WITHIN-CANADA  is-a  FLIGHT  with 


r-attrs 


flight#:  1  1 : : 499 

departure,  destination: 


end 
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The  redefined  properties  of  FLIGHT  for  its  specializations 
INTERNATIONAL-FLIGHT  and  FLIGHT-WITHIN-CANADA  must  satisfy  the  IS-A 
constraint,  and  they  do.  Thus,  the  domain  of 

( I  500: :999  | } 

is  automatically  treated  as  a  specialization  of 
{ I  1:  :999  1  }. 

The  same  applies  for  the  aggregate  classes 
[|  citytCITY,  country rCOUNTRY  |] 

and 

[|  city;CITY,  country  :{|  'CANADA'  |}  |]  . 

The  second  is  treated  as  a  specialization  of  the  first  because  its 
properties  are  (respectively)  refinements  of  those  of  the  first. 

According  to  the  IS-A  constraint,  any  combination  of  specializa¬ 
tions  of  the  classes  PERSON,  FLIGHT  and  DATE  must  have  a  "reserve- 
seat"  complex  property  whose  value  (a  transaction)  must  be  a  speciali¬ 
zation  of  the  transaction  RESERVE-SEAT.  Intuitively,  this  means  that 
the  "reserve-seat"  transaction  for,  say  CHILD  and  INTERNATIONAL-FLIGHT 
(and  DATE)  .  must  have  at  least  the  prerequisites,  actions  and  results 
of  RESERVE-SEAT  and  possibly  more.  For  example,  suppose  we  wish  to 
enforce  a  (rather  conservative)  constraint  whereby  each  child  must  be 
accompanied  by  its  guardian  on  an  international  flight.  This  is 
clearly  a  constraint  concerning  the  transaction  (CHILD, 
INTERNATIONAL-FLIGHT,  DATE) .. reserve-sea t .  It  can  be  added  to  that 
transaction  as  a  prerequisite  as  follows: 

prereq  accompanied-by-guard ian?  on 

ICHILD, INTERNATIONAL-FLIGHT, DATE) . .reserve-seat  is 
[p. guardian,  f. flight#, d]  is  RESERVATION 

The  p,  f  and  d  parameters  are  inherited  from  RESERVE-SEAT.  This  addi¬ 
tional  prerequisite  simply  checks  that  the  guardian  of  p  (where  p  is 
assumed  to  be  a  child)  has  also  reserved  a  seat  on  the  same  flight. 

As  another  example,  suppose  that  any  person  (adult  or  child) 
entering  Canada  must  have  "status"  value  'citizen', 
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prereq  status-ok?  on 

, (PERSON < FLIGHT, DATE) . .reserve-seat  is 
p. status. IS  II  'citizen',  'landed-immigrant' 

,  'visitor'  I)  or  not  f. destination. country  =  'CANADA' 

As  a  final  example  of  how  specializations  of  RESERVE-SEAT  might  be 
modified  to  suit  particular  combinations  of  specializations  of  PERSON 
and  FLIGHT,  suppose  we  expect  that  the  income  tax  office  must  be  noti¬ 
fied  for  any  citizens  or  landed  immigrants  leaving  Canada. 

action  notify-income-tax-people  on 

(ADULT, INTERNATIONAL-FLIGHT, DATE) . .reserve-seat  is 
if  (p. status  =  'citizen'  or 

?. status  =  'landed-immigrant')  and 

not  f . destination. country  =  'CANADA') 

IFY- INCOME-TAX-PEOPLE ( p , f , d ) 

This  action  has  no  effects  if  its  Boolean  condition  is  false. 

Once  these  properties  have  been  added  to  their  corresponding 
transactions,  the  expression  reserve-seat (p, f ,d)  has  quite  different 
meanings  depending  on  whether  p  is  an  adult  or  a  child  and  f  is  an 
international  or  local  flight.  Generally, 

reserve-seat  (p , f , d )  = 

(Type(p),  Type(f),  Type (d) ).. reserve-seat (p, f ,d) 

where  Type(x)  returns  (one  of)  the  least  general  class  that  has  x  as 
instance.  If  there  is  more  than  one  such  class,  then  it  is  assumed 
that  choosing  between  them  does  not  affect  the  value  or  the  side- 
effects  by  the  call. 

The  examples  above  illustrate  the  following  points  about  IS-A 
hierarchy : 

1.  It  is  not  only  data  objects  (e.g.,  relations  and  aggregates) 

that  can  be  organized  into  an  IS-A  hierarchy,  but  also  semantic 
integrity  constraints  (expressed  as  prerequisites  and  results)  and 
database  actions; 

2.  Parts  of  the  IS-A  hierarchy  determine  the  structure  of  other 

parts  through  the  definition  of  properties.  For  example,  the  part  of 
the  IS-A  hierarchy  which  appears  below  the  transaction  RESERVE-SEAT  is 
an  isomorphism  of  the  cross-product  of  the  IS-A  hierarchies  which 
appear  below  PERSON,  FLIGHT  and  DATE. 

Point  2  above  along  with  the  IS-A  constraint  can  serve  as  power¬ 
ful  guiding  principles  for  the  construction  of  an  IS-A  hierarchy. 
More  on  this  point  later. 
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2.£.  More  on  Classes 

In  this  section,  we  will  discuss  in  more  detail  some  of  the 
built-in  metaclasses  mentioned  in  Section  2.1. 


2.4.1.  Test  Defined  Classes 

Aggregate,  finitely-defined  and  form-classes  are  all  special 
cases  of  the  general  collection  of  test-defined  classes.  Such  classes 
are  characterized  by  the  fact  that  membership  in  their  extension  is 
determined  by  a  transaction  defined  for  this  purpose: 

(ANY,  TEST-DEFINED-CLASS) . . test  =  TEST-TRANSACTION 
This  complex  property  specializes  for  aggregate  classes  to 

(AGGREGATE,  AGGREGATE-CLASS) .. test  =  TEST- AGGREGATE , 
where  AGGREGATE  is  a  specialization  of  ANY  with  all  possible  aggre¬ 
gates  as  instances.  Similarly,  we  have 

(ANY,  FINITELY-DEFINED-CLASS) . . test  =  FINITE-TEST 

and 

(STRING,  FORM-CLASS) . .test  =  FORMAT-TEST 
where  STRING'S  extension  contains  all  strings  and  TEST- AGGREGATE, 
FINITE-TEST  and  FORMAT-TEST  are  all  specializations  of  TEST- 
TRANSACTION.  The  essence  of  these  three  transactions  was  already 
given  in  the  discussion  of  aggregate,  finitely-defined  and  form- 
classes.  For  instance,  TEST- AGGREGATE ( x ,  C)  checks  that  the  com¬ 
ponents  of  aggregate  x  are  instances  of  the  p-values  of  C's  attribute 
properties. 

Not  all  test  transactions  are  predetermined  as  they  are  for 
aggregate,  finitely-defined  and  form-defined  classes.  For  example, 
assume  that  we  have  an  aggregate  class  DATE  defined  as 

aggregate  DATE  with 
attrs 

month : 
day ; 
year: 

end 

We  can  define  a  class  called  GOOD-DATE  to  reject  dates  like  "feb-30" 
by  declaring  GOOD-DATE  to  be  an  instance  of  a  metaclass  GOOD-DATE- 
CLASS,  which  in  turn  is  a  specialization  of  TD-CLASS  with  the  test 
property  specialized,  i.e.. 


1:  :12 
1:  :31 
60:  :99 
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metaclass  GOOD-DATE-CLASS  is-a  TD-CLASS; 

attr  test  on  GOOD- DATE-CLASS ,  ANY- TOKEN  is  TEST-GOOD-DATE; 
TEST-GOOD-DATE  is  defined  to  be  a  transaction  to  test  legal  dates 


transaction  TEST-GOOD-DATE  is-a  BOOLEAN-TRANSACTION  with 
jarams  ^date j , good-da^^) ; 

da 

actions 

begin 

month  <-  date. month; 

if  month  =  1  or  month  =  3  or  month  =  5 

or  month  =  7  or  month  =  8  or  month  =  10 
or  month  =  12  then  day  <-  31; 
else  if  month  =  2  then 

if  date. year  nod  then 

day  <-  29; 

else  day  <-  28 ; 
else  day<-  30; 

good-date  <-  (aate.day<=  day) ; 
end 

end 


2.4.2.  Relations 


Every  relation  class  has  factual  properties  get-object,  insert- 
object  and  remove-object.  Since  TAXIS  is  expected  to  interface  with  a 
reasonably  sophisticated  relational  DBMS,  a  high  level  of  predefined 
operations  are  provided.  The  implication  of  offering  the  extra  level 
is  that  efficiency  can  be  enhanced  if  it  is  known  that  a  relation  will 
be  modified  with  respect  to  several  relation  instances  residing  in 
primary  or  secondary  storage  (i.e.,  in  other  relations).  For  example, 
if  MANAGER  IS-A  EMPLOYEE,  the  following  statement. 


retrieve  for  x  in  EMPLOYEE 
for  Y  in  MANAGER 
into  FATCATS (x . name ,  x.sal) 
where  (x.dept  =  y.dept  and  x.sal  >  y.sal) 

retrieves  into  the  relation  FATCATS  employees  making  more  than  one  of 
his/her  managers.  It  is  worth  noting  that  the  assumption  MANAGER  IS-A 
EMPLOYEE  allows  a  rather  clean  expression  of  the  query.  The 
"retrieve"  operation  is  similar  in  form  to  the  RETRIEVE  command  of 
QUEL.  However,  it  assumes  that  the  relation  where  retrieved  informa¬ 
tion  is  to  be  stored  is  predefined. 

No  classes  (relation  or  otherwise)  can  be  created  as  results  of 
run-time  operations  in  a  TAXIS  program.  Otherwise,  significant  run¬ 
time  interpretation  would  be  required  to  determine  the  semantics  of 
the  created  class. 


Ve:^h 


1 : 
ATE 


Ji  II,  montn  : t |  1 :  : 12  | | 
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Expressions  and  Statements 

Expressions  can  only  appear  in  TAXIS  programs  as  values  of  prere¬ 
quisite,  result  properties  and  part  of  statements.  As  such,  the  dis¬ 
cussion  in  this  section  does  not  apply  to  class  constructions,  i.e., 
expressions  involving  @,  [|  I’  r  f |  |}f  which  are  evaluated  at  compila¬ 
tion  time. 

The  IS-A  relationship  between  expressions  is  defined  differently 
from  other  classes.  It  is  defined  through  a  predicate  as  follows.  If 
E  and  E'  are  values  of  prerequisite  or  result  properties,  then 

true  if  E  =>  E’ 

P(E,E')  = 

false  otherwise 

In  general,  the  IS-A  hierarchy  of  TAXIS  expressions  is  defined  as  fol¬ 
lows:  if  T  and  T'  are  transactions  and  T  IS-A  T'  and  p  is  a  prere¬ 
quisite,  action  or  result  property  of  T  and  T' ,  then  T..p  IS-A  T'..p 
iff  P (T. .p,T' . .p) .  Thus,  a  prerequisite  property  p  of  a  transaction 
T'  can  only  be  redefined  in  a  specialization  of  T' ,  say  T,  if  the  new 
prerequisite  value,  i.e.,  T..p,  implies  the  old  one,  i.e.,  T’..p.  If 
this  is  not  the  case,  it  is  not  true  that  T..p  IS-A  T'..p  and  the  IS-A 
constraint  is  violated. 

Consider,  for  example,  a  specialization  of  the  RESERVE-SEAT  tran¬ 
saction,  say  T,  for  which  the  prerequisite  "seat-left?"  must  be  rede¬ 
fined,  It  makes  sense  to  redefine  it  as  follows 

prereq  seats-left?  on  T  is  f.seats-left  >  10 

since  f.seats-left  >  10  =>  f.seats-left  >  0.  The  redefinition,  how¬ 
ever  , 

prereq  seats-left?  on  T  is  f.seats-left  >0  or  p.age  <  2 

is  inappropriate  because  f.seats-left  >  0  or  p.age  <  2  ~=>  f.seats- 

left  >  0. 

In  TAXIS,  statements  like  insert,  delete  and  replace  entities  are 
provided.  Conditional,  block  and  looping  constructs  are  available  to 
construct  compound  statements  from  the  simpler  ones.  Given  two  state¬ 
ments  S  and  S',  the  IS-A  predicate  P  is  defined  as  follows: 

true  if  S  causes  at  least  the 

side-effects  caused  by  S' 

P(S,  S')  = 

false  otherwise 

The  formalization  of  the  predicate  poses  one  of  the  more  challenging 
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and  interesting  problems  in  the  TAXIS' s  design.  More  on  this  in 
Chapter  Five. 

Transactions 

We  have  already  presented  the  basic  types  of  properties  one  can 
associate  with  a  transaction.  Through  prerequisite,  action  and  result 
properties  the  TAXIS  user  can  "factor  out"  a  transaction  body  into 
semi-independent  constraint  checks  and  actions  that  may  be  associated 
with  a  transaction  directly  or  through  inheritance. 

There  are  a  number  of  predefined  transactions  which  can  be  used 
to  perform  basic  operations  on  instances  of  TAXIS  classes.  For  exam¬ 
ples,  the  relational  operators  on  relations,  the  arithmetic  operators 
of  INTEGER  and  REAL. 

£.^.5.  Exceptions 

We  have  adapted  Wasserman's  (Wasserman  [77])  procedural 
exception-handling  mechanism  with  modifications  that  allow  exceptions 
and  exception-handling  to  be  treated  in  the  context  of  classes,  pro¬ 
perties  and  the  IS-A  hierarchy. 

Exception  classes  are  classes  whose  instances  can  be  created  (we 
use  the  word  raised  )  and  destroyed  (when  the  raised  exception  is  han¬ 
dled)  .  Unlike  relations,  they  can  only  have  attribute  properties. 
They  can  also  be  defined  and  organized  into  an  IS-A  hierarchy.  For 
example,  assume  that  we  have  exception  classes  SECURITY-EXCEPTION  and 
CONSTRAINT-EXCEPTION.  Consider  for  the  World  of  Seat  Reservations  the 
exception  class  NO- SEATS- LEFT: 


exception  NO-SEATS-LEFT  is-a  CONSTRAINT-EXCEPTION  with 
attrs 

pers:  PERSON; 

fit  FLIGHT; 

date:  DATE; 

end 


When  an  instance  of  this  exception  class  is  created,  its  properties 
will  automatically  be  assigned  values  through  which  one  will  have 
information  about  the  circumstances  under  which  the  exception  was 
raised . 

Exceptions  are  raised  when  a  prerequisite  or  a  result  evaluate  to 
a  value  other  than  true.  To  specify  which  exception  should  be  raised, 
one  must  associate  with  a  prerequisite  or  result  value  (an  expression) 
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an  exception  class.  This  is  done  through  an  exception  property 

exc-property  exc  on  RESERVE-SEAT. . seats-left? 

is  NO-SEATS-LEFT(pers:p,flt:f ,date:d) , 

where  the  associations  pers:p,  flt:f  and  date:d  specify  the  values 
that  must  be  assigned  to  the  properties  of  the  NO-SEATS-LEFT  instance 
that  is  raised  when  the  prerequisite  "seats-lef t?"  fails. 

When  an  exception  is  raised  within  a  transaction  T,  it  is  up  to 
the  caller  of  T  to  specify  what  should  be  done  to  handle  the  excep¬ 
tion.  Such  specifications  come  in  the  form  of  complex  properties 
called  exc-handlers  that  take  as  subjects  an  expression  E  and  an 
exception  EXC  and  as  value  an  exception-handling  transaction  H,  and 
cause  the  execution  of  H  if  an  instance  of  EXC  is  raised  during  the 
evaluation  of  E.  Suppose,  for  example,  that  the  transaction  CALLER 
calls  RESERVE-SEAT  or  one  of  its  specializations  during  the  execution 
of  one  of  its  actions,  say  "act".  To  indicate  that  the  transaction 
FIND- ALTERNATIVE  should  be  called  if  the  exception  NO-SEATS-LEFT  is 
raised,  we  write 

transaction  CALLER  with 
actions 

act :  reserve- seat  (p»  f  £.d) 

exc-handler  eh  for  NO-SEATS-LEFT 

is  FIND- ALTERNATIVE 

end 

which  defines  a  configuration  as  illustrated  in  fig.  2.6.  Now,  if  an 
instance  of  NO-SEATS-LEFT  is  raised  during  the  evaluation  of  reserve- 
seat(p,f,d),  FIND- ALTERNATIVE  will  be  called  with  the  newly  created 
exception  instance  as  argument.  From  the  attribute  properties  of  this 
instance,  FIND- ALTERNATIVE  will  determine  the  circumstances  of  the 
exception  and,  hopefully,  what  should  be  done. 

Treating  exceptions  and  exception-handling  in  terms  of  classes, 
properties  and  the  IS-A  hierarchy  means  that  the  already  existing  IS-A 
hierarchy  of  data  classes  and  their  operations  can  be  used  to  struc¬ 
ture  exception-handling  procedures  within  a  TAXIS  program.  We  will 
illustrate  this  point  by  extending  the  example  we  have  used  so  far  so 
that  if  a  NO-SEATS-LEFT  instance  is  raised  for  a  child,  it  is  not  only 
for  the  child  that  an  alternative  is  found  but  also  for  his/her  guar¬ 
dian.  First  we  create  a  specialization  of  NO-SEATS-LEFT: 
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exception  NO-SEATS-LEFT-FOR-CHILD  is-a  NO-SEATS-LEFT  with 
r-attrs 

guardian;  ADULT; 

end 


Then  we  redefine  the  exception  property  of  "exc"  of  the  "seats-lef t?" 
prerequisite  for  the  transaction  (CHILD,  INTERNATIONAL- 
FLIGHT)  . .reserve-seat 


exc-property  exc  on  (CHILD,  INTERNATIONAL-FLIGHT) . . 

reserve-seat .. seats-lef t?  is 
NO-SEATS-LEFT-FOR-CHILD (per s IP, f It : f , date ; d , 

guar  a  lamp,  guardian) 

Finally,  we  augment  the  exception  handler  FIND- ALTERNATIVE  for  the 
exception  handling  property  "eh"  of  CALLER.. act  and  NO-SEATS-LEFT- 
FOR-CHILD 


action  f ind-alternative-for-guardian-too  on 

(CALLER. .act,  NO-SEATS-LEFT-FOR-CHILD) . .eh  is 
/*  remove  the  child's  guardian  from  the  flight  fit 
and  reserve  a  seat  for  him/her  as  well  on  the 
alternative  flight  selected  */ 

We  will  not  present  TAXIS  code  for  the  new  action  defined  for  the 
exception-handler  for  NO-SEATS-LEFT  exceptions.  It  is  worth  noting, 
however,  that  the  IS-A  hierarchy  of  exception-handlers  is  patterned 
after  that  of  relations  along  with  their  operations. 

Following  this  informal  description,  this  thesis  will  give  three 
formal  descriptions  of  TAXIS,  i.e.,  the  syntactic,  denotational  and 
axiomatic  definitions,  in  Chapters  Three,  Five  and  Six  respectively. 
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Figures  of  Chapter  2 


PERSON 


john-smi th 


name - >  PERSON-NAME 

address  - >  ADDRESS-VALUE 

age - >  AGE-VALUE 

phone#  - >  PHONE#-VALUE 

Fig .  2.1 

name - >  'SMITH,  JOHN,  B.  ' 

address  - >  '13,  PAULA  AVE. ' 

age - >  32 

phone#  - >  7624377 


Fig.  2.2 


PERSON 


create 

- > 


CREATE-PERSON 


PERSON 

FLIGHT 


Fig.  2.3 
reserve-sea 

reserve-sea 
Fig.  2.4 


RESERVE-SE/TI 


PERSOInL— - 

Teserv^sllT:X:^>  RESERVE- SEAT 
FLIGHT _ _ 


Fig .  2.5 

reserve-seat  [p,  f  ,g] 


CALLER 


NO-SEAT-LEFT_ 
Fig .  2.6 


IND-ALTERNATIVE 
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Syntax  and  informal 
Semantics  of  Taxis 


Table  of  Contents 

2-  Syntax  and  Informal  Semantics  of  TAXIS 

3.1  Notations  and  Basic  Vocabulary 

3.2  Identifiers  and  Numbers 

3.3  Tokens  and  Permanent  Assignments 

3.4  Simple  Class  Definitions 

3.4.1  Finitely  Defined  Classes 

3.4.2  Form  Defined  Classes 

3.4.3  Simple  Aggregate  Classes 

3.5  Property  Definitions 

3.6  Metaclass  Definitions 

3.6.1  Built-in  Metaclasses 

3.6.2  The  IS-A  Relationship  for  Metaclasses  and  Classes 

3.7  Data  Class  Definitions 

3.7.1  Relation  Classes 

3.7.2  Exception  and  Aggregate  Classes 

3.8  Expressions 

3.8.1  Binary  Operators 

3. 8. 1.1  Property  Selection  Operators 

3. 8. 1.2  Arithmetic  Operators 

3. 8. 1.3  String  Operator 
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3.8.3  Attribute  Function  Expressions 

3.9  Statements 

3.9.1  Property  Modification 

3.9.2  Transaction  Call 

3.9.3  Conditional 

3.9.4  Block 

3.9.5  While 

3.9.6  For 

3.9.7  Operator  Statements 

3. 9. 7.1  Get  Object 

3. 9. 7. 2  Insert  and  Delete 

3. 9. 7. 3  High  Level  Relational 

3.10  Transaction  Class  Definitions 

3.11  TAXIS  Programs 


_3*1*  Notations  and  Basic  Vocabulary 

This  chapter  presents  the  syntax  and  an  informal  semantics  of 
TAXIS. 

The  notation  used  to  express  the  syntactic  rules  is  a  modified 
Backus-Naur  Form  with  the  following  notational  conventions 

Nonterminals  are  denoted  by  strings  of  English  words  with  capi¬ 
tal  letters  as  first  characters. 

'='  is  used  instead  of  the  standard  symbol  to  separate  the 

left  from  the  right  hand  side  of  productions. 

Concatenation  (denoted  by  one  or  more  blanks)  of  syntactic  con¬ 
structs  has  higher  precedence  over  alternation  (denoted  by  '[')• 
Metabrackets  (  and  )  can  be  used  to  overrule  this  precedence. 
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Possible  repetition  (0  or  more  instances)  of  a  construct  is 
indicated  by  metabrackets  {  and 

Possible  omission  of  a  construct  is  indicated  by  enclosing  the 
construct  within  metabrackets  [  and  ]  . 

Nonterminals  of  the  form  C-list  generate  one  or  more  occurrences 
of  C,  i.e.,  are  a  shorthand  notation  for  C  {  C  }. 

The  nonterminal  Empty  generates  the  empty  character  sequence. 

The  basic  vocabulary  includes  letters,  digits  and  special  symbols 
and  they  are  defined  as  follows 


Letter  =  A  |  B 

1  C  1  D  1  E 

1  F  1  G 

1  H  1  I 

1  J  1  K  i 

L  1 

M  1  N 

1  0  1  P 

1  Q  1  R  1  S 

1  T  1  U 

1  V  1  W 

1  X  i  Y  1 

Z 

1  a  1  b 

1  c  1  d  1  e 

1  f  1  g 

1  h  1  i 

M  1  k  1 

1  1 

m  1  n 

1  o  1  P 

1  q  1  r  1  s 

1  t  1  u 

1  V  1  w 

1  X  1  y  1 

z 

Digit  =  0  1  1 

1  2  1  3  1  4  1 

5  1  6 

1  7  1  8 

1  9  1  , 

Special- symbol 

=  <  1  -  1  1 

1  =  1  : 

1  ^  1 

>!<=!> 

=  1 

(  1 

MIN 

+  1  1  M}  1 

[|  1  1 

1  1  ■  1 

f  1  ;  1  ^  1 

1 

1  $ 

1  )  1  #  1 

*  i  M  ••  1 

/  1  nothing  | 

11 

1  is  1  succ  1  pred  |  It  |  gt 

1  le  1  ge  1  attr 

1  params 

1  prereq  |  action  | 

result  1 

key  1  exc 

1  local  1 

exc-property 

1  exc- 

handler 

1  is-a 

1  total  1 

metaclass  | 

with 

1  relation  |  aggregate 

1  nil 

1  for  1 

mod  1  1 1 

1  true  1 

false  1  <- 

1  if  1  then  |  begin  | 

else  1 

while  1 

do  1  in 

1  where  | 

get-object  | 

insert 

-object 

1  and  1  on 

1  retrieve  |  delete  | 

replace 

1  into 

1  from 

1  transaction  |  r-attr 

1  end 

1  remove 

-object 

TAXIS  comments  are  delimited  by  /*,  */,  i.e.,  have  the  form 
'/*'  Any-sequence-of-symbols-not-containing-*/  »*/•  be 

inserted  between  any  two  constructs. 


3.2.  Identifiers  and  Numbers 

Identifiers  are  used  to  associate  names  to  classes,  tokens  and 
property  attributes.  Numbers  are  tokens  and  they  can  be  integers  or 
reals. 
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Identifier  =  Letter  {  Character  } 

Character  =  Letter  |  Digit  |  Break-symbol 
Break-symbol  =-|  ?|  #|  *|  :  |  $ 

Number  =  Integer  |  Real 
Integer  =  [  -  1  Digit  {  Digit  } 

Real  =  Integer  .  Digit  {  Digit  }  I  E  [  +  |  -  ]  Digit 

[  Digit  ]  ] 


Examples 

Identifiers:  Person,  si#,  graduate-student?,  How-many$ 

Integers:  2,  -123 

Reals:  -1.3,  1.3E+23,  26.034E-1 


Token  Variables  and  Permanent  Assignments 

Tokens  are  the  constants  of  TAXIS.  An  atomic  token  is  either  a 
number  or  an  atom.  An  aggregate  token  is  an  instance  of  an  aggregate 
class  (section  3.4)  and  is  similar  in  several  ways  to  a  Pascal  record. 
An  atom  is  a  character  string.  Within  an  atom,  two  quotes  in  succes¬ 
sion  denote  a  single  quote. 


Token  =  Atomic-token  |  Aggregate- token 
Atomic-token  =  Number  |  Atom 
Atom  =  '  {  Character  |  ' 

Aggregate-token  =  [  Attribute-value-list  '' 

Attribute-value  =  Identifier-list  :  Token 

Names  can  be  associated  to  TAXIS  objects  (tokens  or  simple  classes 
(section  3.4))  through  the  permanent  assignment  operator 

Variables  in  TAXIS  belong  to  a  property  category  called  locals. 
Only  blocks  and  transactions  can  have  local  properties.  There  are  two 
types  of  variables,  relational  tuple  and  value  variables.  The  former 
behave  like  pointers  in  that  several  variables  can  refer  to  the  same 
tuple  and  modification  to  the  tuple  affects  all  those  variables  refer¬ 
ring  to  it.  Value  variables  can  be  of  types  integer,  string  and 
class. 

Permanent-assignment  = 

Identifier  :=  (  Simple-class-definition  |  Token  ) 
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Examples 

Atomic  tokens:  213,  2.1345E+22,  ' john-smi th ' , 

'this  is  an  atom  -  a  string',  'Don"t' 

Aggregate  token:  [  no:13,  street  :'pauline',  city:  'toronto'  ^ 
Permanent  assignments:  five  :=  5, 

COLOR  :=  {|  'green',  'red',  'yellow'  |} 

The  built-in  transaction  SUBSTR  can  be  used  to  select  a  subpart 
of  an  atom. 

SUBSTR(A,  i,  1)  where  A  is  an  atom,  i  and  1  are  integers,  returns 
the  part  of  A  starting  with  the  ith  position  up  to  and  including  the 
(i+l)th  position  of  A. 


2.4.  Simple  Class  Def init ions 

TAXIS  has  special  facilities  for  the  definition  of  simple 
classes.  Such  classes  can  include  finitely-defined,  form-defined  or 
aggregate  classes.  Their  definition  can  be  followed  by  a  list  of 
classes  each  of  which  is  taken  to  be  a  generalization  of  the  newly 
defined  class. 

Simple-class-definition  =  Simple-class  [  is-a  Class-list  ' 

Simple-class  =  Finitely-defined 

I  Form-defined 
I  Aggregate-class 


Finitely  Defined  Classes 

A  finitely-defined  class  is  similar  to  a  Pascal  scalar  type  where 
an  ordered  set  of  tokens  is  enumerated  and  serves  as  class  definition. 
A  finitely-defined  class  can  also  be  defined  by  specifying  a  list  of 
subranges  of  other  finitely-defined  classes. 

Finitely-defined  =  {|  Token-list  |  Interval-list  |} 

Interval  =  Token  : :  Token 

Examples 

(1  1,3, 5, 7, 9  |}  is-a  INTEGER 
{|  1::5,  10:: 15  |}  is-a  INTEGER 

{|  [  no:13,  street paul  ine '  ],  [  no:31,  str  ee  t :  '  paul '  p 
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Note  that  for  a  class  A  defined  in  terms  of  subranges,  the  subranges 
must  refer  to  the  classes  of  which  A  is  a  specialization.  TAXIS  has 
the  following  built-in  finitely-defined  classes; 

BOOLEAN  is  predefined  to  be 

{  I  false  ,  true  | 1 

INTEGER  is  the  set  of  integers  within  a  range  of  maximum  and 
minimum  integers  (determined  by  the  underlying  computer  system)  and 
predefined  as  follows 

{|  min-int ; :max-int  |1 

Operators  succ,  pred.  It,  gt,  le  and  ge  are  predefined  for  every 
finitely-defined  class  (section.  3 . 8 .1 )  . 

Form  Defined  Classes 

A  form-defined  class  defines  a 
which  is  specified  by  applying  the 
tion)  to  classes. 

Form-defined  =  Class  |  Class  @ 

Examples 

Digit  @  Digit  @  l|  '/'  P  @  Digit  @  Digit  @  {|  '/'  P 

@  Digit  @  Digit 

defines  a  class  whose  instances  have  the  form  dd/dd/dd,  where  each  d 
is  a  digit,  and  represent  dates. 

The  built-in  function  REPEAT  is  defined  by 

REPEAT(D,n)  =  D  @  D  @  D  ...  (n  times) 

Example 

{|  '('  P  @  REPEAT(Digit,3)  @  ('  ')'  P  @  REPEAT(Digit  ,7) 

defines  a  class  whose  instances  are  tokens  of  the  form  (ddd)ddddddd 
where  each  d  is  a  digit,  and  represent  phone  numbers. 

1.^.3.  S imple  Aggregate  Classes 

A  simple  aggregate  class  is  similar  to  a  Pascal  record  type  with 
no  variant  fields. 

Aggregate-class  =  ( [  Attribute-property-list  | ’ 


set  of  tokens  matching  a  pattern, 
associative  operator  @  (concatena- 

Form-def ined 
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Attribute-property  =  Identifier-list  ;  Class 
Examples 

[|  si# : SI# -VALUE,  birth-date :DATE ,  age ; AGE -VALUE  |' 

[|  no  : INTEGER,  street:  STREET-NAME,  city  :{|  'TORONTO'  p  |] 


3^._5.  Property  Definitions 

A  property  is  a  triple 
(Subjects,  Attribute,  P-value) 

where  Subjects  is  a  single  class  (e.g.  INTEGER)  or  an  n-tuple  of 
classes  (e.g.,  (PERSON,  COURSE)).  Attribute  is  an  identifier  and  P- 
value  is  another  class. 

We  will  often  use  the  property  attribute  as  name  for  the  property 
when  there  is  no  ambiguity.  To  define  a  property  one  must  specify,  in 
addition  to  its  subjects,  attribute  and  p-value,  the  property's  type 
which  determines  how  the  property  will  be  used  in  the  program. 

Property-definition  =  Property-category  Identifier  on 

Class-list  is  Class 


Property-category  =  attr 

1  r-attr  | 

params  |  prereq 

1  key  1  exc 

1  local  1 

exc-proper  ty 

1  result  1 

exc-handler 

1  action 

Class  =  Class-name  |  Simple-class 
Class-name  =  Identifier 


I  (  Class-name-list  )  (  ..  |  .  )  Identifier 
I  Class-name  (  . .  |  .  )  Identifier 


Examples 

r-attr  age  on  PERSON  is  AGE-VALUE 

attr  enrol  on  STUDENT, COURSE  is  ENROL-TRANSACTION 

Properties  defined  for  a  class  C  under  any  of  the  property 
categories  are  called  def Initional  properties  of  C.  Instances  of  C 
will  have  properties  with  the  same  attributes  called  factual  proper¬ 
ties  .  The  p-values  of  such  properties  must  be  instances  of  the  p- 
values  of  the  corresponding  definitional  properties. 

In  the  first  example  above,  a  (definitional)  r-attribute  property 
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is  defined  with  subject  PERSON,  value  AGE-VALUE  and  attribute  the 
identifier  age.  In  the  second  example  above,  a  (definitional)  attri¬ 
bute  property  is  defined  with  subjects  STUDENT  and  COURSE,  value  the 
transaction  ENROL-TRANSACTION  and  attribute  the  identifier  enrol.  An 
instance  of  STUDENT  and  an  instance  of  COURSE  have  an  enrol  factual 
property. 

If  the  class-list  to  which  the  property  is  associated  contains 
more  than  one  class,  then  the  property  is  called  a  complex  property, 
otherwise  it  is  called  a  simple  property  or  just  property.  The  first 
example  above  involves  a  simple  property  while  the  second  a  complex 
one . 

Values  of  a  definitional  property  for  a  class  (or  classes)  can  be 
accessed  through  the  operator.  For  example, 

(STUD ENT, COURSE) . .enrol 

returns  the  transaction  ENROL-TRANSACTION.  Similarly,  values  of  fac¬ 
tual  properties  are  accessed  through  the  operator,  as  in, 

john-smi th . age 

which  returns  the  p-value  of  the  age  attribute  of  john-smith. 

h'—'  Metaclass  Definitions 

A  metaclass  definition  begins  with  the  keyword  metaclass  ,  fol¬ 
lowed  by  an  identifier  as  the  name  of  the  new  metaclass,  then  an 
optional  list  of  metaclasses  as  generalizations  to  the  new  metaclass, 
and  finally,  the  property  definitions  of  the  metaclass.  Metaclasses 
can  only  have  properties  from  the  r-attribute  and  attribute 
categories.  Instances  of  a  class  can  not  have  their  factual  attribute 
properties  modified  whereas  instances  of  a  class  can  have  their  fac¬ 
tual  r-attribute  properties  modified.  Each  attribute  or  r-attribute 
property  has  an  optional  clause:  total-  The  total  clause  imposes  the 
restriction  that  the  attribute  or  r-attribute  property  of  each 
instance  of  the  class  cannot  be  equal  to  nothing. 

Metaclass-definition  = 

mctaclass  Identifier  [  is-a  Identifier-list  ] 

with  [  Attribute-category  ]  [  R-at tr ibute-ca tegory  ]  end 
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Attribute-category  =  attrs  Attribute-list 
Attribute  =  Identifier-list  :  Class 

[  total  1 

R-attr ibute-category  =  r-attrs  Attribute-list 
Examples 

metaclass  STUDENT-CLASS  is-a  RELATION-CLASS  with 
r-attrs 

grade-average:  NUMBER 

end 

STUDENT-CLASS  is  defined  to  be  a  metaclass  and  a  specialization  of 
another  metaclass  called  RELATION-CLASS-  Every  instance  of  STUDENT- 
CLASS  (e.g.,  GRADUATE-STUDENT)  will  have  grade-average  as  factual  pro¬ 
perty. 


3.6.1.  Built-in  Metaclasses 


TAXIS  has  built-in  metaclasses  with  predefined  properties  and 
they  are  predefined  as  follows: 


metaclass 

metaclass 

metaclass 

metaclass 

metaclass 

metaclass 

metaclass 

metaclass 

metaclass 

metaclass 

metaclass 


ANY-CLASS 

DATA-CLASS  is-a  ANY-CLASS 
EXPRESSION-CLASS  is-a  ANY-CLASS 
STATEMENT-CLASS  is-a  ANY-CLASS 
TRANSACTION-CLASS  is-a  ANY-CLASS 
TD-CLASS  is-a  DATA-CLASS 
FORM-CLASS  is-a  TD-CLASS 
FD-CLASS  is-a  TD-CLASS 
AGGREGATE-CLASS  is-a  TD-CLASS 
RELATION-CLASS  is-a  IDD-CLASS 
EXCEPTION-CLASS  is-a  IDD-CLASS 


V 


ANY-CLASS  is  the  most  general  metaclass.  DATA-CLASS, 
EXPRESSION-CLASS,  STATEMENT-CLASS  and  TRANSACTION-CLASS  will  be 
presented  in  sections  3.7,  3.8,  3.9  and  3.10  respectively. 

TD-CLASS  is  a  metaclass  with  a  predefined  complex  property  called 

test 

(ANY,  TD-CLASS) .. test  =  TEST-TRANSACTION 
where  ANY  is  a  built-in  instance  class  of  DATA-CLASS  whose  instances 
are  the  set  of  all  tokens.  The  built-in  transaction  TEST-TRANSACTION 
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can  be  specialized  to  make  special  membership  test  (section  2.4.1). 

The  built-in  transaction  INSERT-T  inserts  an  instance  into  an 
RELATION  class  and  all  of  its  generalizations.  The  built-in  transac¬ 
tion  REMOVE-T  deletes  an  instance  t  from  all  the  classes  which  have  t 
as  an  instance.  The  built-in  transaction  GET-T  retrieves  an  instance 
from  an  RELATION  class  which  satisfies  certain  condition.  Section 
3.9.2  gives  more  information  about  these  three  operations. 

FD-CLASS  (Finitely-Defined  Class)  is  a  specialization  of  TD-CLASS 
whose  instances  are  all  the  finitely-defined  classes  (  section  3.4.1). 

FORM-CLASS  (Form-Defined  Class)  is  another  specialization  of  TD- 
CLASS  whose  instances  are  all  the  form-defined  classes  (section 
3.4.2)  . 

A  special  class  called  NONE-CLASS  has  the  class  NONE  (the  class 
with  no  instances)  as  the  only  instance.  NONE  is  a  specialization  of 
all  classes,  and  has  no  instances  at  all. 

2.*£*?.*  The  ^“A  Relationship  for  Metaclasses  and  Classes 

The  IS-A  relationship  for  metaclasses  and  classes  has  the  follow¬ 
ing  properties 

I.  IS-A  is  a  partial  order. 

II.  If  A  IS-A  B,  then  every  instance  of  A  is  also  an  instance  of 

B. 

III.  If  A  IS-A  B  and  B  has  simple  property  p,  then  A  too  has  pro¬ 

perty  p  and  A..p  IS-A  B..p.  Similarly,  if  B  is  one  of  the  sub¬ 
jects  of  complex  property  p,  i.e.,  p  has  subjects  Cl ,  C2 ,  . . . ,  Cn 
and  Ci=B,  then  A  too  is  one  of  the  subjects  of  complex  property  p 
and  such  that  (Cl ,C2 , . . . , A, . . . ,Cn) . . p  IS-A 

(Cl ,C2 , . . . ,B , . . . ,Cn) . .p,  (Cl ,C2 , . . . , A, . . . ,Cn) . .p  f 

(Cl , C2 ,...,B,...,Cn) ..p. 

IV.  There  is  a  most  general  (maximum)  and  a  most  specialized 
(minimum)  class  w.r.t.  IS-A  called  respectively  ANY  and  NONE. 
Similarly,  there  is  a  most  general  and  a  most  specialized  meta¬ 
class  called  respectively  ANY-CLASS  and  NONE-CLASS. 

^.7.  Data  Class  Definitions 

An  instance  C  of  metaclass  DATA-CLASS  can  have  properties  from 
three  categories,  keys,  attributes  and  r-attr ibutes .  A  key  property 
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specifies  a  subset  of  the  attribute  properties  of  the  class  C,  and 
each  attribute  property  in  the  subset  must  be  a  data  class  and  defined 
to  be  total.  All  instances  of  C  must  have  distinct  key  values.  Attri¬ 
bute  and  r-attribute  properties  have  the  same  meaning  as  discussed  in 
section  3.6. 

Data-class-def inition  = 

Identifier  Identifier  [  is-a  Class-list  ] 

with  [  Key-category  ]  [  Attribute-category  ] 

[  R-attr ibute-category  ]  end 

Key-category  =  keys  Key-property-list 

Key-property  =  Identifier  :  (  Identifier-list  ) 

A  data  class  definition  begins  with  an  identifier  which  names  the 
metaclass  DATA-CLASS  or  any  of  its  specializations,  followed  by  an 
identifier  as  the  name  of  the  new  class,  then  an  optional  is-a  clause, 
finally,  the  body  of  the  three  property  categories.  A  key  property  of 
a  class  associates  a  name  to  a  list  of  identifiers  each  of  which  must 
be  declared  to  be  an  attribute  property  of  the  class. 

Relation  Metaclass 

Only  instances  of  metaclass  RELATION-CLASS  and  its  specializa¬ 
tions  can  have  properties  from  all  three  categories  keys,  attributes 
and  r-attr ibutes . 

Examples 

relation  PERSON  with 
keys 

id:  (si#) 
attrs 

si#:  REPEAT (DIGIT, 9) 

r-attrs 

phone#:  PHONE# -VALUE 
age:  AGE-VALUE 

bir th-date :DATE 

end 

metaclass  STUDENT-CLASS  is-a  relation  with 
r-attrs 

cardinality:  INTEGER 

end 
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STUDENT-CLASS  STUDENT  is-a  PERSON  with 
keys 

stid:  (st#) 

attrs 

St#:  REPEAT (DIGIT, 7) 

r-attrs 

grades:  GRADE 


end 


3 .7.2  . 

Exception  and  Aggregate  Metaclasses 

Instances  of  the  built-in  metaclasses  EXCEPTION-CLASS  and 
AGGREGATE-CLASS  can  only  have  attribute  properties.  If  EXP  is  an 
exception  class,  then  an  instance  of  EXP  is  created  ('raised')  if  a 
prerequisite  or  a  result  of  a  transaction  returns  a  value  not  equal  to 
true  and  if  the  prerequisite  or  result  can  raise  such  an  exception 
(section  3.9).  This  exception  instance  is  deleted  when  the 
exception-handling  transaction  that  is  called  to  handle  it  has  com¬ 
pleted  its  execution. 

Aggregate  classes  can  be  defined  separately  (see  example  below) . 
The  distinguishing  feature  of  an  aggregate  class  is  that  its  collec¬ 
tion  of  instances  is  predefined  to  be  the  cross  product  of  all  its 
attribute  property  values.  Instances  of  aggregate  classes  are  never 
changed  (like  pure  LISP  lists) . 


Examples 


aggregate  DATE  with 


end 


exception  NO-SEAT-LEFT  is-a  SEMANTIC-EXCEPTION  with 
attrs 


p: PERSON 
c : CLASS 


end 


8 .  Expression 

Expressions  are  similar  to  Pascal  expressions. 


Expression  =  nil 


I  Identifier 
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I  [  Expression 

I  Token 

I  Expression  Binary-operator 
Expression 

I  Unary-operator  Expression 

I  Attribute-function-expression 

nil  is  an  "empty”  expression  which  always  return  nothing  as  value.  An 
identifier  denoting  a  class  or  a  token  will  return  as  value  the 
corresponding  class  or  token. 

Binary  Operators 

TAXIS  has  the  following  groups  of  binary  operators. 

Binary-operator  =  Property-selection-operator 

I  Arithmetic-operator 
I  String-operator 
I  Relational-operator 
!  Logical-operator 

These  groups  of  operators  are  listed  in  decreasing  order  of  pre¬ 
cedence.  All  except  the  assignment  operator  and  ’**'  are  left- 
associative.  If  one  of  the  operands  has  value  nothing  ,  then  the 
result  of  the  binary  operation  is  nothing. 

^.8.1.1.  Property  Selection  Operators 

Property-selection-operator  =  ..  |  . 

The  right  operand  of  must  be  an  attribute,  while  the  left 

operand  defines  the  subject (s)  of  the  property  whose  p-value  is  to  be 
found.  The  left  operand  can  itself  be  a  property  selection  expres¬ 
sion.  Since  the  subjects  must  be  of  type  class,  these  expressions  are 
called  class  expressions.  Similar  comments  apply  for  If  p.a 

returns  a  token  as  result,  the  expression  is  called  a  token  expres¬ 
sion.  If  p.a  returns  a  tuple  as  result,  the  expression  is  called  a 
tuple  expression.  If  C..p  has  value  a  transaction  T,  then  for  an 
instance  c  of  C  the  expression  c.p  is  equivalent  to  the  transaction 
call  T(c).  Similarly,  if  cl,  c2 ,  . . . ,  cn  have  complex  property  p 
whose  value  is  a  transaction  T,  then  (cl ,c2 , . . . ,cn) .p,  where  cl,  c2 , 
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. cn  are  instances  of  Cl ,  C2 ,  . . . ,  Cn  respectively,  is  equivalent 
to  the  transaction  call  T (Cl ,C2 , . . . ,Cn) .  Examples 


ENROL-TRANSACTION. . seat-left?  (returns  an  expression) 

STUDENT.. age 

(STUDENT, COURSE) ..enrol 

nohn-smith. guardian. age 

(john-smith,cscl48) .enrol  is  equivalent  to 
ENROL-TRANSACTION (john-smith,cscl48) 


^.8^.1.^.  Arithmetic  Operators 

Arithmetic-operator  =  <  |  -  |  *  |  **  |  nod 
The  left  and  right  operands  must  be  expressions  which  return  numbers 
as  values. 

3^.£.l.^.  Str ing  Operator 

String-operator  =  | | 

Both  operands  must  be  atoms.  Examples 

'toronto*  II  ', Ontario'  has  value  ' toronto,ontar io ' 


3. 8. 1.4.  Relational  Operators 


Relational-operator  =  <  |  >  |  <=  |  >=  |  is 

I  is-a  I  It  I  gt  I  le  I  ge 

The  operators  <,  >,  <=  and  >=  are  the  relational  operators  for 
numbers.  The  operators  It  (less  than) ,  gt  (greater  than) ,  le  (less  t 
han  or  equal  to)  and  ge  (greater  than  or  equal  to)  accept  tokens  from 
the  same  finitely-defined  class  and  return  true  or  false  according  to 
the  order  the  tokens  are  ennumerated. 

The  left  operand  of  is  must  be  a  token,  the  right  operand  a 
class.  is  returns  true  or  false  depending  on  whether  the  token  is  an 
instance  of  the  class  or  not. 

Both  operands  of  is-a  must  be  classes  or  metaclasses.  An  expres¬ 
sion  involving  is-a  returns  true  if  its  left  operand  is  a  specializa¬ 
tion  of  the  right  operand. 


^.8.1.5.  Log ical  Operators 


Logical-operator  =  or  |  and 
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The  operands  must  be  of  class  BOOLEAN. 

3^.8.^.  Unary  Operators 

Unary-operator  =  -  |  pred  |  succ  |  not 

-  is  the  unary  negation  operator  for  arithmetic  expressions. 

The  operands  for  pred  and  succ  are  instances  of  finitely-defined 
classes.  pred  returns  the  preceding  token  of  a  finitely-defined 
class,  succ  returns  the  succeeding  one.  Examples 
pred  (4)  is  3 

succ  (’red')  is  'yellow'  for 
the  class  {|  'green',  'red',  'yellow'  |}. 

^.8.^.  Attr ibute  Function  Expressions 

Attribute-function-expression  = 

Identifier  (  Simple-expression-class-list  ) 

[  Exception-handler-list  ] 

The  identifier  must  be  a  property  attribute  and  the  expression  list 
evaluates  to  a  list  of  objects  (classes  or  tokens)  which  are  subjects 
of  a  factual  property  with  the  same  property  attributes.  The  meaning 
of  the  expression  p(el ,e2 , . . . ,en)  is  equivalent  to  (el , e2 , . . . , en) . p 
when  the  definitional  p-value  of  p  is  not  a  transaction.  Examples 

age(p)  =  p.age 

cardinality (STUDENT)  =  STUDENT. cardinality 

If  the  value  of  p  is  a  transaction  and  p  is  a  factual  property  among 
objects  el,  e2 ,  ...,  en,  then  the  meaning  of  p (el , e2 , . . . , en)  is 

equivalent  to  the  following  transaction  call. 

(Type (el) ,Type (e2 ) , . . . ,Type (en) ) . .p  (el , e2  ,  .  .  .  ,en) 

where  Type  is  a  built-in  transaction  which  takes  a  token  as  argument, 
and  returns  (one  of)  the  most  specialized  class  of  which  the  token  is 
an  instance. 

Example 

If  enrol  is  a  complex  property  between  STUDENT  and  COURSE,  i.e., 
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attr  enrol  on  STUDENT, COURSE  is  ENROL-TRANSACTION 

then  the  meaning  of 

enrol ( john-smith ,  cscl48) 


is 


Type ( john-smith) ,Type (cscl48) ) . . enrol ( john-smith,cscl48) 

Hence,  depending  on  which  are  the  most  specialized  classes  to 
which  john-smith  and  cscl48  belong,  different  enrol  transactions  will 
be  called. 


9 .  Statements 

Statements  are  classified  into  seven  groups. 

Statement  =  Property-modification 
I  Transaction-call 
I  Conditional 
I  Block 
I  While 
1  For 

I  Operator-statement 

^.9.1.  Property  Modification 

Property-modification-operator  =  <- 

The  left  operand  of  the  assignment  operator  must  be  a  factual 
property  selection.  The  right  operand  is  an  expression  which  must 
return  a  value  of  the  same  class  or  a  specialization  of  the  class  of 
the  left  operand. 

Examples 

X  <-  5 

john-smith .guardian. phone#  <-  1234567 
STUDENT. cardinality  <-  STUDENT. cardinality  +  1 

It  is  important  to  stress  that  only  two  property  categories  allow 
modification  of  p-values:  r-attrs  for  metaclass  and  relation  class 
instances,  and  locals  (variables)  for  blocks  and  transaction 
instances . 
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Transaction  Call 

A  transaction  is  called  by  giving  the  name  of  the  transaction, 
followed  by  two  lists  of  arguments  separated  by  The  first  is  a 

list  of  expressions  whose  values  are  taken  as  the  factual  property 
values  of  the  value  parameters  of  the  transaction.  The  second  list  is 
a  list  of  variable  names  which  are  taken  as  the  reference  parameters 
of  the  transaction.  If  the  class  of  an  argument  is  not  the  same  as 
the  class  of  the  corresponding  parameter,  then  the  following  conver¬ 
sion  rule  determines  the  legality  of  the  call: 

Conversion  rule  for  transaction  calls  :  If  t-arg  is  the  class  of 
an  argument,  and  t-par  is  the  class  of  the  corresponding  parameter  of 
the  transaction,  then  conversion  will  take  place  only  if  t-arg  is  a 
specialization  of  t-par. 

A  transaction  call  can  be  followed  by  an  optional  list  of  excep¬ 
tion  handlers.  This  construct  is  used  to  associate  an  exception¬ 
handling  transaction  to  an  exception  which  may  be  raised  by  the  tran¬ 
saction  during  its  execution.  If  an  instance  of  the  exception  is 
raised  by  a  prerequisite  (or  result)  of  the  transaction,  then  the 
handler  is  invoked  with  the  exception  instance  as  an  argument.  The 
handler  always  returns  control  to  the  next  prerequisite  (or  result)  of 
the  transaction  where  the  exception  was  raised. 

Transaction-call  =  Class  (Expression-list ; Identif ier-list) 

[  Exception-handler-list  ] 

Exception-handler  =  exc-handler  for  Class-name  is  Class-name 
Example 

ENROL -TRANS ACT I ON  ( ; john-smi th ,  cscl48) 

exc-handler  for  COURSE-FILLED  is  FIND-OTHER-COURSE 

Conditional  Statement 

A  conditional  statement  selects  a  statement  for  execution  based 
on  the  value  of  a  (Boolean)  expression.  If  the  condition  returns  true 
,  then  the  statement  after  the  symbol  then  is  executed;  if  it  is  false, 
then  the  statement  after  the  symbol  else  is  executed  (if  there  is  an 
else  clause) . 
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Condit ional= 

if  Expression  then  Statement 

[  else  Statement  ] 


Example 


if  p.age  >  32  then  p.sal  <-  p.sal  +  100 

else  p.sal  <-  p.sal  +  50 


^.£.£.  Block  Statement 

The  block  statement  specifies  a  sequence  of  statements  to  be  exe¬ 
cuted  sequentially.  It  is  bracketed  by  a  pair  of  symbols,  begin  and 
end-  After  the  symbol  begin,  it  is  followed  by  an  optional  local  vari¬ 
able  list  and  the  block  body.  The  block  body  can  be  either  a  sequence 
of  statements  or  a  sequence  of 

Block-statement  =  begin  [  Local-variable-category  ] 

Block-body 

end 

Local-variable-category  =  local  Variable-list 

Variable  =  Identifier  :  Class-name 

Block-body  =  Statem.ent-proper  ty-list 

Statement-property  =  [  (  Identifier  |  Empty  )  ]  [  :  ] 

[  Statement-class  ]  ; 

If  the  user  does  not  provide  an  identifier  on  the  left  side  of  ' : '  for 
an  expression  property,  then  a  unique  system-generated  identifier  is 
substituted  as  the  property  name.  This  name  can  not  be  accessed  by 
any  specialization  of  this  block,  hence  it  is  guaranteed  that  the 
expression  property  can  not  be  redefined.  Examples 

begin 

bl ;enrol ( iohn-smith ,cscl48) 

b2 : STUDENT. cardinality  <-  STUDENT. cardinality  +  1 

end 


3.9.5.  While  Statement 


while -statement 


=  while  Expression  do 

Statement-list 


end 
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The  body  of  while  expressions  is  executed  repeatedly  (0  or  more  times) 
until  the  expression  after  the  symbol  while  returns  a  value  not  equal 
to  true- 
Example 

while  X  >  0  do 

y  <-  y  *  y 

X  <-  X  -  1 

end 


3^. 9^. 6.  For  Statement 

The  for  statement  specifies  that  a  sequence  of  statements  is  to 
be  executed  repeatedly  and  at  the  beginning  of  each  cycle,  the  vari¬ 
able  after  the  symbol  for  is  assigned  a  new  value  from  a  class.  The 
class  can  either  be  a  finitely  defined  class  or  a  relation  class.  The 
for  expression  is  exited  when  the  class  is  exhausted.  In  the  case  of 
a  relation  class,  no  insertion  or  deletion  of  instances  from  the  rela¬ 
tion  can  take  place  in  the  for  body. 

For-statement  =  for  Identifier  in  Class  do 

Statement-list 

end 


Example 


for  i  in  ( I  1 : : 5  [ }  do 
sum  <-  sum  +  i 

end 


for  s  in  STUDENT  do 

s. average  <-  s. average  +  10.00 

end 


2.*^*Z*  Operator  Statement 

Operator  statements  are  basically  the  operations  for  relation 
classes . 

Operator-statement  =  Get-object-statement 

I  Idd-statement 

I  High-level- relational-statement 
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Get  Object  Statement 

Get-object-statement  = 

get-object  from  Class-name 

with  (  Expression  ) 

Operation  get-object  is  a  simple  retrieval  primitive  for  RELATION 
classes.  get-object  returns  the  first  instance  in  the  class  which 
satisfies  the  with  expression.  Token  nothing  is  returned  if  no  such 
instance  exists. 

Example 

get-object  for  e  in  STUDENT 
with  (e.stud  =  john-smith  ) 

will  return  the  instance  in  ENROLLMENT  whose  student  attribute  has  p- 
value  john-smith,  if  such  an  instance  exists. 

Idd  Statement 

Idd  statements  use  the  predefined  properties  of  the  metaclass 
RELATION -CLASS. 

Idd-statement  =  Insert-statement 

I  Remove-statement 

Insert-statement  =  insert-object  Identifier  in  Class-name 

with  Expression 

Remove-statement  =  remove -object  Identifier 

The  identifier  after  the  symbol  insert-object  must  be  declared  as  a 
tuple  variable  of  type  class-name.  The  class  name  in  insert-object 
must  be  defined  as  an  instance  of  the  metaclass  RELATION-CLASS  or  its 
specializations.  The  Expression  must  evaluate  to  a  token  which  has 
property  attributes  matching  those  of  the  class-name.  Moreover,  the 
p-values  of  the  token's  properties  must  be  instances  of  the 
corresponding  p-value  classes.  The  effect  of  an  insert  statement  is 
to  make  the  newly  created  token  an  instance  of  the  class  and  also  an 
instance  of  all  the  classes  which  are  generalizations  of  the  class. 
Also,  the  variable  is  pointing  at  the  new  token.  The  key  properties 
of  the  token  must  be  unique  to  all  the  instances  in  the  class. 

The  effect  of  remove -object  is  to  delete  the  token  which  the 
Identifier  is  referring  to.  Examples 
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insert-object  in  PERSON  with  si# :12345678  ,  phone :2 468012 
remove-object  john-smith 

1*?.*Z*2-*  High  Level  Relational  Statements 

The  high  level  relational  statements  are  similar  to  those  in  QUEL 
without  aggregate  functions.  An  identifier  declared  after  the  for 
symbol  is  called  a  tuple  variable  (TV)  which  is  a  local  variable  pro¬ 
perty  with  p-value  a  relation  R  and  TV  is  used  to  "range"  over  a  rela¬ 
tion.  The  where-clause  is  a  Boolean  expression  describing  a  selection 
condition  in  terms  of  the  tuple  variables.  The  meaning  of  a  retrieve 
operation  is  that  the  cross  product  of  the  relations  declared  to  have 
tuple  variables  is  formed  and  for  each  tuple  in  the  cross  product,  the 
where  clause  is  evaluated,  and  if  it  is  true  then  the  list  of  simple 
expressions  is  evaluated,  the  token  with  property  values  the  results 
of  these  expressions  is  inserted  into  the  class  which  appeared  after 
the  symbol  into.  For  delete  operation,  the  identifier  after  the  symbol 
from  is  called  a  tuple  variable  (TV)  which  is  a  local  variable  pro¬ 
perty  with  p-value  a  relation  R.  The  delete  statement  considers  each 
instance  of  R  in  turn,  assigns  it  to  TV  and  then  deletes  it  if  it 
satisfies  the  where  clause.  The  identifiers  of  the  assignments  in  the 
replace  body  must  be  r-attribute  property  names  of  the  relation  class. 
The  meaning  of  a  replace  operation  is  similar  to  retrieve  except  that 
the  instances  of  the  relations  are  modified  instead  of  created. 

High-level-relational-operator  = 

Quel-operator  for  Tuple-var ible-list 

(  Retrieve-body  |  Delete-body  |  Replace-body  ) 

[  Where-clause  ] 

Quel-operator  =  retrieve  |  delete  |  replace 
Tuple-variable  =  Identifier  in  Class-name 
Retrieve-body  =  into  Class-name  (  Expression-list  ) 

Delete-body  =  from  Identifier 

Replace-body  =  Identifier  (  Assignment-list  ) 

Assignment  =  Identifier  <-  Expression 
Where-clause  =  where  (  Expression  ) 

Examples 

retrieve  for  st  in  STUDENT  into  GOOD-STUDENT  (st.st#,  st. grade) 
where  (st. grade  gt  'B+'  ) 
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delete  for  st  in  STUDENT 

froB  St 

where  (st. grade  It  'D-'  ) 


replace  for  st  in  STUDENT 
for  e  in  ENROLMENT 
st. average  <-  st. average  +  10 

where  (st  =  e. student  and  e. course  =  'science') 


Transaction  Class  Definitions 

Transaction  classes  can  have  properties  from  the  following 
categories  params  ,  locals  ,  prereqs,  actions  and  results.  There  can 
only  be  one  property  from  the  params  property  category  for  each  tran¬ 
saction.  As  a  result,  the  property  is  assigned  params  attribute 
unless  otherwise  specified  in  the  transaction  definition.  params  pro¬ 
perties  consists  of  two  group  of  identifiers  separated  by  a  The 

first  is  for  value  parameters,  the  latter  is  for  reference  parameters. 
Prerequisites  and  results  must  return  Boolean  values.  An  exception 
class  can  be  associated  to  each  prerequisite  or  result.  An  instance 
of  the  exception  class  is  created  if  the  prerequisite  or  result 
returns  a  value  not  equal  to  true.  The  properties  of  the  exception 
instance  take  on  the  values  of  the  simple  expression  list  associated 
to  the  exception. 

Transaction-definition  = 

transaction  Identifier  [  is-a  Class-name-list  1 
with 

[  params  [  (  Identifier-list  )  ] 

[  Local-variable-category  ] 

[  prereqs  Condition-property-list  ] 

[  actions  Statement-property-list  1 
[  results  Condition-property-list  ] 

end 

Condition-property  =  Expression-property  [  exc  Class-name 

(  Expression-list  )  ] 

The  order  of  evaluation  of  properties  in  a  transaction  is  as  follows; 
first  all  the  prerequisites  are  evaluated,  and  if  they  all  return  true 
,  then  all  the  actions  are  executed,  followed  by  all  the  results. 

Property  (section  3.8.2  .2)  of  the  form 
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pi  ; 

can  be  used  to  order  the  inherited  prerequisites,  actions  or  results 
relative  to  the  prerequisites,  actions  and  results  of  the  current 
transaction.  Of  course,  all  prerequisites  must  precede  all  actions 
which  in  turn  must  precede  all  results  in  this  user-defined  order. 
Example 

If  A  and  B  are  transactions  such  that  A  is-a  B  and  B  has  three 
action  properties  pi,  p2 ,  p3 .  A  can  have  its  own  action  property 
inserted  between  pi  and  p2  as  follows 


transaction  A  is-a  B 

actions 

pi 

p4:  E; 

P2 

P3 


end 


Because  of  semantic  constraints  imposed  on  TAXIS  (see  Chapter 
Seven) ,  ordering  the  actions  of  a  transaction  A  relative  to  those  of 
its  generalizations  can  only  have  minimal  effects. 


Taxis  Programs 

A  TAXIS  program  consists  of  class  definitions,  property  defini¬ 
tions  and  permanent  associations  of  names  to  TAXIS  objects  (classes  or 
tokens  ) . 

Program  =  Statement-list  . 

Statement  =  Class-definition  |  Property-definition 
I  Permanent-assignment 
Class-definition  =  Metaclass-definition 

1  Simple-class-definition 
I  Data-class-def inition 
I  Transaction-definition 

In  the  next  chapter,  a  detailed  example  is  given  in  the  language  for 
the  design  of  an  interactive  information  system:  students  enrollments. 
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4.5.2  More  Extensions  of  REGISTER 
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4.1.  Introduction 


The  design  methodology  for  IISs  is  based  on  the  concept  of  spe¬ 
cialization.  Starting  with  a  general  IIS  design,  a  more  detailed  sys¬ 
tem  is  obtained  by  specializing  the  existing  classes.  This  process  is 
carried  out  in  a  stepwise  fashion  until  the  desired  level  of  detail  is 
obtained.  More  specifically,  an  IIS  is  specialized  as  follows. 
First,  the  data  classes  (e.g.,  relations)  are  specialized.  Next,  the 
operations  associated  to  the  data  classes  are  specialized.  Then  the 
exception  classes  are  specialized  to  model  the  violations  of  the  more 
detailed  checking  performed  in  the  operations.  And  finally,  the 
exception  handlers  are  specialized  to  handle  the  more  detailed  clas¬ 
sification  of  the  exceptions. 

An  IIS  design  using  the  specialization  methodology  can  be  viewed 
(or  used)  at  several  levels  of  abstraction,  where  more  and  more 
details  are  modelled  as  one  moves  down  the  ISA  hierarchies  of  classes. 
This  allows  different  users  to  understand  and  use  the  system  at  dif¬ 
ferent  levels  depending  on  their  interests  or  position  in  the  enter¬ 
prise.  It  is  also  relatively  easy  to  integrate  details  and  special 
cases  of  an  IIS  design  through  specialization.  This  is  because  the 
concepts  are  organized  and  classified,  and  given  a  piece  of  detail, 
the  most  specialized  concepts  relevant  to  the  information  can  be 
located  in  the  network  of  concepts  and  modelling  of  the  information 
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can  be  done  at  that  level.  In  general,  the  specialization  principle 
offers  a  mechanisin  for  organizing  details  of  an  IIS.  It  should  be 
noted  that  modifications  of  TAXIS  programs  are  easy  as  long  as  they 
take  place  at  the  bottom  of  the  IS-A  hierarchy.  Other  modifications 
higher  up  on  the  IS-A  hierarchy  may  involve  re-organization  of  the 
classes  below  the  point  of  modification.  At  each  step  of  the  special¬ 
ization,  special  rules  (IS-A  constraints)  have  to  be  observed.  The 
observation  of  the  IS-A  constraints  guarantees  that  each  extension  of 
an  existing  IIS  will  result  in  a  compatible  and  more  detailed  system. 

In  this  chapter,  the  design  methodology  of  stepwise  refinement 
through  specialization  is  demonstrated  by  giving  a  detailed  design  for 
a  student  enrollment  system.  The  design  is  achieved  through  four 
layers  of  specializations.  Except  for  the  most  general  level,  each 
layer  constitutes  a  self-contained  system  which  can  be  used  without 
any  assumptions  about  the  existence  of  lower  layers.  The  layers  are 
described  individually  in  sections  4.2  to  4.5. 


4.2.  The  Basic  Level 


Information  systems  require  basic  facilities 
ing  and  activity  logs.  Since  every  activity 
ingredients,  it  is  best  to  model  them  in  the  most 
any  activity  defined  later  will  inherit  these 
generalizations . 


for  security  check- 
involves  these  basic 
general  level.  Then 
ingredients  from  its 


4.2.1.  Basic  Data  Classes 


Assume  that  only  persons  known  to  the  system  are  allowed  to  use 
it;  hence,  the  concept  of  persons  has  to  be  defined.  Also  assume  that 
we  are  interested  in  the  following  information  about  each  person: 
his/her  social  insurance  number,  address,  name  and  phone  number.  A 
class  PERSON  can  be  defined  as  follows 


relation  PERSON  with 
keys 

ident :  (si# ) ; 

attrs 

si#:  SOC I AL- INSURANCE# -VALUE; 

r-attrs 

address:  ADDRES S -VALUE ; 

n  ame :  NAME -VALUE ; 

phone# :  PHONE# -VALUE ; 

end 
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There  is  a  special  breed  of  persons  who  are  authorized  to  update  the 
contents  of  the  database.  Let's  call  such  people  administrators.  A 
new  class  ADMINISTRATOR  is  defined  as  a  specialization  of  PERSON  with 
an  additional  property:  the  administrator's  position  in  the  univer¬ 
sity. 


relation  ADMINISTRATOR  is-a  PERSON  with 
r-attrs 

position:  POSITION-VALUE; 

end 

The  values  of  the  attributes  and  r-attributes  of  PERSON  and  ADMINIS¬ 
TRATOR  are  defined  next.  Some  of  the  more  interesting  classes  of 
ADDRESS  are  defined  below.  SOCIAL- INSURANCE# -VALUE  and  PHONE#-VALUE 
are  defined  to  be  form-defined  data  classes.  PHONE#-VALUE  defines  a 
set  of  tokens  of  the  form  (ddd) ddd-dddd  where  d  is  a  digit.  ADDRESS 
and  NAME  are  defined  to  be  aggregate  classes.  POSITION-VALUE  is 
defined  to  be  a  finitely-defined  data  class. 

SOCIAL-INSURANCE# -VALUE  =  REPEAT (  DIGIT, 9) 


aggregate  ADDRESS  with 
attrs 

no : 

street : 
province : 
country: 
postal-code : 

end 


aggregate  NAME  with 
attrs 

last-name:  LAST-NAME-VALUE; 

first-name , middle-name :  FIRST-NAME -VALUE; 

end 


POSITIVE-INTEGER; 
STREET-NAME ; 
PROVINCE; 

COUNTRY; 
POSTAL-CODE ; 


PHONE# -VALUE 


{  ' ( '  1}  @  REPEAT (  DI 

@  REPEAT (  DIGIT, 3  )  @ 
REPEAT (  DIGIT, 4  ) 


POSITION-VALUE  :=  {[  ' chairman ',' co-chairman ',' assoc-chairman ' , 

' assist-to-chairman' , ' chairman-secretary* . ' secretary! ' ,  , 

'secretary!',  ' secretaryl ' ,  'receptionist',  'mailperson'  |}; 

From  now  on,  we  will  omit  the  definition  of  some  of  the  "obvious"  sim¬ 
ple  data  classes  or  simply  define  them  "in-line"  wherever  they  are 
needed.  POSTAL-CODE  is  a  set  of  tokens  of  the  form  Idlbdld  where  1 
stands  for  a  letter,  b  a  blank  and  d  a  digit. 
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POSTAL-CODE  :=  LETTER  @  DIGIT  @  LETTER  @  {I  '  '  H  @  DIGIT 

@  LETTER  @  DIGIT 

To  define  the  class  POSITIVE-INTEGER,  we  define  a  metaclass  (call  it 
POSITIVE- INTEGER-CLASS)  which  is  a  specialization  of  metaclass  TD- 
CLASS. 

metaclass  POSITIVE-INTEGER-CLASS  is-a  TD-CLASS 

The  attribute  property  test  of  TD-CLASS  and  ANY-TOKEN  (Chapter 
Three,  section  3.6.1)  is  refined  to  have  a  transaction  called  TEST¬ 
POSITIVE. 

attr  test  on  POSITIVE-INTEGER-CLASS,  INTEGER  is  TEST-POSITIVE; 
TEST-POSITIVE  is  defined  simply  as  follows: 

transaction  TEST-POSITIVE  with 

Sarams  ( integer ; result) ; 
ocals 

integer < result :  INTEGER; 
result  <-  (integer  >  0); 

end 

Now  POSITIVE-INTEGER  can  be  defined  as  an  instance  of  POSITIVE- 
INTEGER-CLASS. 

POSITIVE-INTEGER-CLASS  POSITIVE-INTEGER  is-a  INTEGER; 

The  expression,  where  i  is  an  integer, 
test  (POSITIVE-INTEGER,  i) 

returns  true  or  false  depending  on  whether  i  is  a  positive  integer  or 
not. 

Basic  Transaction  Classes 

The  security  checking  and  bookkeeping  requirements  mentioned  pre¬ 
viously  can  be  modelled  as  the  body  of  the  most  generic  transaction, 
call  it  ANY-TRANSACTION.  The  requirement  that  only  persons  known  to 
the  system  are  allowed  to  use  it  is  simply  a  prerequisite  of  ANY- 
TRANSACTION.  The  bookkeeping  can  be  done  in  the  action  part  of  the 
same  transaction. 
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transaction  AN Y-TRANS ACTION  with 
locals 

X  :  TRANSACTION-LOGBOOK; 
prereqs 

authorized?:  $user  is  PERSON 

exc  UNAUTHORIZED-USE (user:  $user  ); 

/*  authorized  checks  whether  the  user  is  an 
instance  of  PERSON.  If  not,  exception 
UNAUTHORIZED-USE  is  raised.  $user  is  one 
of  the  few  system  variables  that  identifies 
the  current  user  of  the  system.  */ 

actions 

enter-logbook:  insert-object  x  in  TRANSACTION 

-LOGBOOK  with 

transaction:  $self  ,  arguments:  params  ; 

/*  enter-logbook  records  the  current  transaction 
(which  is  identified  by  the  system  variable  $self 
as  well  as  its  parameters)  in  a  system  relation 
TRANS ACT I ON -LOG  for  recovery  and  diagnostic  purposes  */ 

end 


Since  ANY-TRANSACTION  is  the  most  generic  transaction,  any  transaction 
defined  below  will  have  authorized?  as  the  first  prerequisite  to  be 
checked,  and  any  unknown  user  will  be  stopped  by  the  system  as  the 
exception  UNAUTHORIZED-USE  is  raised. 


exception  UNAUTHORIZED-USE  is-a  SECURITY-EXCEPTION  with 
attrs 

user:  PERSON; 

end 


Suppose  that  we  want  to  associate  an  exception  handler  called 
GENERATE-MESSAGE,  to  any  expression  and  UNAUTHORIZED-USE. 


exc-handler  eh  on  ANY-EXPRESSION ,  UNAUTHORIZED-USE  is 

GENERATE-MESSAGE 


Since  every  expression  is  a  specialization  of  ANY-EXPRESSION,  the 
statement  above  means  that  if  an  instance  of  UNAUTHORIZED-USE  is  ever 
raised,  then  the  transaction  GENERATE-MESSAGE  is  invoked. 

For  the  special  kind  of  transaction  which  can  modify  the  data¬ 
base,  it  is  required  that  only  administrators  above  a  certain  rank  can 
invoke  them.  To  model  this  requirement,  a  specialization  of  the  tran¬ 
saction  ANY-TRANSACTION  is  defined,  call  it  UPDATE,  where  the  prere¬ 
quisite  authorized?  is  refined  to  carry  stricter  security  checking. 


transaction  UPDATE  is-a  ANY-TRANSACTION  with 
prereqs 

authorized?:  $user  is  ADMINISTRATOR  and 

$user .position  ge  'secretary' 
exc  UNAUTH0RIZE5-UPDATE(user :$user ) 

/*  only  administrators  with  rank  at  least 
as  nigh  as  secretary?  are  allowed  to 
update  the  database  */ 

end 


More  specialized  updating  transactions  can,  of  course,  restrict 
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authorized?  further  (e.g.,  to  the  point  where  only  the  department 
chairman  can  update  student  files).  The  exception  UNAUTHORIZED-UPDATE 
is  a  specialization  of  UNAUTHORIZED-USE. 

exception  UNAUTHORIZED-UPDATE  is-a  UNAUTHORIZED-USE 

This  implies  that  transaction  GENE RATE -MESSAGE  is  invoked  when¬ 
ever  an  UNAUTHORIZED-UPDATE  exception  is  raised.  Besides  generating 
messages,  harsher  action  can  be  performed: 

actions  on  (ANY-EXPRESSION,  UNAUTHORIZED-UPDATE) .. eh  is  abort 

The  diagram  in  Fig  4.1  summarizes  the  classes  and  their  relationships 
defined  in  this  level  of  design. 

The  system  developed  so  far  is  a  fundamental  level  that  is  useful 
to  other  specialized  levels.  For  example,  any  transaction  which  only 
retrieves  from  the  database  must  be  declared  as  a  specialization  of 
ANY-TRANSACTION.  All  updating  transactions  are  declared  to  be  spe¬ 
cializations  of  UPDATE. 


The  General  Level 

In  this  level,  we  begin  to  define  specialized  classes  to  model 
the  activity  that  enrols  a  student  in  a  course.  As  in  the  previous 
level,  the  necessary  data  classes  are  defined  first;  followed  by  the 
definitions  of  transactions  that  operate  on  the  data  classes,  then  the 
definitions  of  exceptions  which  the  transactions  can  detect,  and 
finally,  the  exception  handling  transactions  which  can  deal  with  these 
exception  situations. 

An  enrollment  involves  a  student,  a  course,  a  semester  and  a  sec¬ 
tion  number. 

A  student  is  a  specialization  of  PERSON  with  additional  proper¬ 
ties:  a  student  can  be  identified  by  a  student  number;  the  properties 
name,  year,  faculty,  and  status  are  also  of  interest 
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relation  STUDENT  is-a  PERSON  with 
keys 

id:  (student#) ; 

attrs 


end 


student#:  REPEAT (DIGIT,  7); 
r-attrs 

faculty:  FACULTY-V^LUE ; 

year:  1::7  [] j 

status:  i|  'part-time'. 


' full-time ' 


# 


FACULTY-VALUE  :=  {|  'applied-math',  ' ar ts-and-science ' ,  ...  , 

'engineering',  'law',  'medicine' 

Assume  that  a  course  can  be  identified  by  a  course  number  and  that  the 
following  information  is  also  of  interest:  the  course  title;  the 
department  giving  the  course;  the  course  description. 


relation  COURSE  with 
keys 

ident:  (course#); 
attrs  .  ,  ,  , 

course#:  {|  100::2999  |}; 

r-attrs 

title:  COURSE-TITLE; 

dept:  DEPT-VALUE; 

descr ip t ion : STRING ; 

end 


DEPT-VALUE  =  {|  'biology',  'chemistry',  'forestry',  ...  p; 

Next,  we  need  three  classes  for  the  information  of  exclusion,  prere¬ 
quisite  and  corequisite  courses  for  every  course. 


relation  EXCLUSION-COURSES  with 
keys 

ident:  (a,b) ; 

attrs 

a,b:  COURSE;  end 


relation  PREREQ-COURSES  with 
keys 

ident :  (c ,prec) ; 

attrs 

c,  prec:  COURSE; 

end 


relation  COREQ-COURSES  with 
keys 

ident:  (c,  coreqc) ; 

attrs 

c,  coreqc:  COURSE; 

end 


Semester  is  defined  to  be  an  aggregate  class  with  attributes  term  and 
year . 
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aggregate  SEMESTER  with 

attrs  .  ,  , 

term:  1  '  f  all '  ,  ,  spr  ing  ’  ,  'summer'  }; 

year:  {  60::99  |}; 

end 


Enrollment  is  defined  to  be  a  relation  representing  that  a  student 
takes  a  course  in  a  semester  at  a  certain  section  of  the  course. 


relation  ENROLLMENT  with 
keys 

ident:  (student, course, semester ,  section#); 

attrs 


student : 
course : 
semester : 
section# : 
r-attrs 

grade : 

end 


STUDENT ; 

COURSE 
SEMESTER; , , 

IT  |}; 

{I  'A+' , 'A' , 'A-' , 

' C- ' , ' D+ '  ,  '  D ' 


'B+'  ,  'B'  ,  'Br,' 
'D-' , 'F' 


c+' 


c , 


A  useful  concept  is  that  of  a  (university)  class.  A  class  is  a  course 
given  during  a  semester.  An  important  property  of  class  is  that  of 
instructor  teaching  the  class.  Instructor  is  defined  first,  then  the 
concept  of  class  is  defined  to  be  an  abstraction  of  the  other  con¬ 
cepts.  An  instructor  is  a  particular  kind  of  person  with  additional 
properties  that  s/he  can  be  identified  by  his/her  name;  and  that  rank, 
salary  and  tenure  information  are  of  interest: 


relation  INSTRUCTOR  is-a  PERSON  with 
keys 

ident:  (name) ; 

r-attrs 

rank:  l|  'researcher',  'assist-prof,  . 

'  assoc-prof  ^  ,  'prof  |}; 

salary:  MONEY; 

tenure:  BOOLEAN; 

end 


MONEY  =  {I  '$'  11  @  POSITIVE-INTEGER  @  {1  '.'  1} 

@  DIGIT  @  DIGIT 

The  concept  of  class  is  now  defined  to  be  an  abstraction  of  a  course, 
a  semester  and  a  section  number  along  with  three  additional  proper¬ 
ties:  an  instructor,  the  maximum  class  size  and  the  current  number  of 
students  in  the  class. 
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relation  CLASS  with 
keys 

ident:  (course,  semester,  section#) 

attrs 


end 


course:  COURSE ; 

semester:  SEMESTER;,, 
section# :  H  1  :  :15  > ; 

r-attrs 

instructor:  INSTRUCTO 

max# , num-of- students : 


1::200  1}; 


4.3.1.  The  ENROL  Transaction 


Next,  a  transaction  called  ENROL  is  defined  to  enrol  students  in 
courses.  ENROL  may  be  associated  with  the  class  STUDENT  (as  a  pro¬ 
perty)  but  also  with  the  class  COURSE.  Hence  we  will  define  ENROL  to 
be  a  complex  property  of  STUDENT  and  COURSE. 


attr  enrol  on  STUDENT , COURSE  is  ENROL; 


In  this  level,  a  student  is  allowed  to  enrol  in  a  course  if  there 
is  such  a  class  for  the  course  (or  an  exception  NO-SUCH-CLASS  is 
raised)  and  there  is  still  space  available.  If  there  is,  the  fact  is 
recorded  in  ENROLLMENT  and  the  number  of  students  is  incremented  by 
one.  Otherwise,  an  exception,  called  CLASS-FILLED,  is  raised  specify¬ 
ing  the  class  is  filled.  The  following  transaction  models  the 
requirements  mentioned  above.  Note  that  the  last  construct  of  the 
block  statements  in  the  transaction's  prerequisites  is  an  expression. 
This  is  a  convenient  notation  to  express  the  values  of  the  complex 
prerequisites  or  results.  In  Chapter  Five  (section  5.7),  the  notation 
is  transformed  into  the  'normal'  TAXIS  syntax. 

transaction  ENROL  is-a  UPDATE  with 
arams  ( s , c , sem, s# )  ; 

1  e 

s :  STUDENT ; 

c :  COURSE 

sem:  SEMESTER; 
s#:  T\  1::15 

class:  CLASS; 
prereqs 

class-there? : 

begin 

class <-  get-object  from  CLASS 
with  ( semester=sem 
and  course=c  and 

section#  =  s#)  ; 

(class  ~=  nothing  )  ; 
end  exc  NO-SUCH-CLAsS (st : s ,  cl:class); 

enough-space? : 

beg  in 

class  <-  g^t-object  from  CLASS 
with  (course  =  c  and 
semester  =  sem  and 
section#  —  s#  ) * 

(class. max#  >  class . num-of-students) ; 
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/*  the  class  corresponding  to  the  course,  semester 
and  section#  is  retrieved  from  the  relation 
CLASS.  The  prerequisite  is  true  if  max#  of 
the  class  is  greater  than  the  num-of-students 
of  the  class.  */ 

end  exc  CLASS-FILLED ( st : s ,  cl;class); 

actions 

insert-tuple:  insert-object  class  in  ENROLLMENT  with 

student  s.  course  c,  semester  sem, 
section#  s# • 

update-class-size:  class. num-of-students  <- 

class . num-of-students  +  1; 

/*  record  the  fact  in  ENROLLMENT  that  the  student 
is  taking  the  course.  Also  increment  the  number 
in  the  class.  */ 

end 

Exceptions  NO-SUCH-CLASS  and  CLASS-FILLED  are  specializations  of 
ENROL-VIOLATION  which  in  turn  is  a  specialization  of  SEMANTIC- 
CONSTRAINT-VIOLATION  with  properties  the  student  and  the  class. 


exception  ENROL-VIOLATION  is-a  SEMANTIC-CONSTRAINT-VIOLATION 

with 

attrs 

St:  STUDENT; 

cl:  CLASS; 

end 


exception  NO-SUCH-CLASS  is-a  ENROL-VIOLATION; 


exception  CLASS-FILLED  is-a  ENROL-VIOLATION; 

According  to  the  exception  handling  mechanism,  when  a  CLASS- 
FILLED  exception  is  raised,  it  is  up  to  the  caller  of  ENROL  to  specify 
a  handler  for  the  exception.  Assume  that  a  transaction,  called  REGIS¬ 
TER,  is  needed  to  enrol  a  student  to  a  set  of  courses.  REGISTER  is  a 
caller  to  ENROL  and  hence  is  responsible  for  the  handling  of  the 
exceptions  raised  by  ENROL. 


The  REGISTER  Transaction 

We  will  define  REGISTER  to  be  a  (simple)  property  of  STUDENT  so 
that  we  can  refine  it  for  different  kinds  of  students. 

attr  register  on  STUDENT  is  REGISTER; 

REGISTER  takes  two  arguments:  a  student  and  a  set  of  courses  the  stu¬ 
dents  intends  to  enrol.  The  action  is  to  invoke  the  ENROL  transaction 
for  each  course  in  the  list.  In  the  case  that  an  exception  is  raised 
by  ENROL,  an  exception  handler  called  ENROL-HANDLER  is  invoked. 
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transaction  REGISTER  is-a  UPDATE  with 

Sarams  (st,  class-list) ; 
ocals 

1  •  <^TTIDFNT  • 

Class-list:  RELATION-CLASS; 
actions 

enrol-loop: 

for  cl  in  class-list  do 

enrol ( St , cl . cour se ,cl . semester ,cl . section# ) 
end  exc-handler  for  ENROL-VIOLATION 
is  ENROL-HANDLER; 

/*  for  each  class  in  class-list,  enrol  the  student 
in  the  course  corresponding  to  the  class.  */ 

end 


Assume  that  when  an  ENROL-VIOLATION  exception  is  raised,  the  main 
action  is  to  print  a  message,  and  hence  we  define  the  exception 
handler  ENROL-HANDLER  to  have  a  simple  action. 


transaction  ENROL-HANDLER  is-a  ANY-EXCEPTION-HANDLER  with 

Sarams  (exception) ; 
oca  Is 

exception:  ENROL-VIOLATION; 

actions 

print  'enrol  for  student'  exception. st  'in  course' 

exception. c  'fails'; 

end 


Assume  that  an  alternative  class  should  be  found  for  the  student  in 
case  a  CLASS-FILLED  exception  is  raised.  So  we  refine  the  handler  for 
CLASS-FILLED  which  is  associated  to  enrol-loop  of  transaction  REGIS¬ 
TER.  The  alternative  criteria  are  that  the  class  should  have  the  same 
course#  as  the  course  in  which  the  student  intends  to  enrol;  that  the 
class  still  has  room  in  it;  and  that  the  section#  of  the  class  is 
different  from  the  original  course.  If  such  a  class  is  found,  the 
original  class  is  changed  into  the  new  class.  Otherwise  the  handler 
aborts  (nothing  else  can  be  done) . 


action  find-alternative  on 

(REGISTER. . enrol-loop ,  CLASS-FILLED) .. eh  is 

begin 

locals 

class:  CLASS; 

class  <-  get-object  from  CLASS 

with  (course#  =  exception . cl . course# 
and  not  section#  = 

exception. cl. section# 
and  max#  >  cl . num-of-students  ); 

/*  find  a  class  from  CLASS  with  the  same  course# 
as  the  class  in  exception.  The  new  class  should 
have  room  in  it.  */ 

if  class  =  nothing  then  abort 

else 

/*  if  such  a  class  is  not  found,  abort  the 

transaction,  else  change  the  old  class  into 
the  newly  found  one.  */ 

end 

The  diagram  in  Fig  4.2  summarizes  the  classes  we  have  defined  in  this 
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level  of  system  design. 


4.4.  A  More  Specialized  Level 


In  this  section,  we  consider  some  special  classes  of  students  and 
courses.  Assume  that  we  have  two  kinds  of  students:  undergraduate  and 
graduate  students,  and  two  kinds  of  courses:  undergraduate  and  gradu¬ 
ate  courses. 

An  undergraduate  student  is  a  student  with  two  other  properties: 
grade-average  and  major. 


relation  UNDERGRAD- STUDENT  is-a  STUDENT  with 
r-attrs 

grade-average:  REAL; 
major:  DEPT-VALUE ; 

end 


A  graduate  student  is  a  student  with  four  additional  r-attr ibutes : 
department,  advisor,  area  and  program. 


relation  GRADUATE-STUDENT  is-a  STUDENT  with 
r-attrs 

department:  DEPT-VALUE; 

advisor:  INSTRUCTOR; 

area:  AREA-VALUE:  , 

program:  i|  'PhD',  'MSc'  |f; 

end 


An  undergraduate  course  is  a  course  whose  course  number  is  between  100 
and  499  and  has  a  "num-of-credi ts"  property. 


relation  UNDERGRAD-COURSE 
r-attrs 


is-a  COURSE  with 


end 


course#:  {1  100::499  |}: 
num-of-cr edits :  1  j  1::4 


A  graduate  course  is  a  course  whose  course  number  is  between  1000  and 
2999. 


relation  GRADUATE-COURSE  is-a  COURSE  with 
r-attrs  , ,  , , 

course#:  {|  1000::2999  |}; 

end 

Now  enrolling  a  student  in  a  course  is  more  complicated,  because  an 
undergraduate  student  has  to  observe  different  regulations  (usually 
stricter)  than  a  graduate  student.  Since  enrol  is  defined  to  be  a 
complex  property  of  STUDENT  and  COURSE,  every  combination  of  speciali¬ 
zations  of  STUDENT  and  COURSE  inherits  an  enrol  property.  It  follows 
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that  each  different  set  of  regulations  associated  with  a  particular 
combination  of  student  and  course  can  be  modelled  by  extending  the 
corresponding  enrol  property. 

We  are  now  ready  to  extend  the  complex  property  enrol  for  some 
combinations  of  specializations  of  STUDENT  and  COURSE. 


4.4.1.  UNDERGRADUATE-STUDENT  Enrolled  in  COURSE 


Suppose  that  an  undergraduate  student  can  take  a  course  if  s/he 
satisfies  the  following  conditions:  that  the  student  did  not  take  a 
course  that  is  exclusive  of  the  course  s/he  wants  to  enrol  in;  that 
s/he  took  all  the  prerequisite  courses;  that  the  deadline  for  enroll¬ 
ment  is  met;  that  less  than  6  courses  are  taken.  Each  of  these  condi¬ 
tions  is  modelled  as  an  additional  prerequisite  of  the  ENROL  transac¬ 
tion  associated  with  UNDERGRAD-STUDENT  and  COURSE.  The  first  condi¬ 
tion  is  a  prerequisite  that  gets  hold  of  all  the  exclusive  courses  of 
the  course  and  checks  if  the  student  has  taken  any  one  of  them.  .  If 
so,  an  exception  called  EXCLUSION-COURSE-TAKEN  is  raised. 


prereq  no-exclusive-course?  on 

on  (UNDERGRAD-STUDENT, COURSE) . .enrol  is 

begin 

l0C3 1 S 

enrol- tuple:  ENROLLMENT; 
f:  BOOLEAN; 

f  <-  true  ; 

for  ex  i  in  EXCLUSION -COURSES  do 

enrol-tuple  <-  get-object  from  ENROLLMENT, 

with  (ex. a  =  c  and  student  =  s  and 
course  —  ex.b  )  * 

/*  try  to  retrieve  a  tuple  from  ENROLLM^INT, 
which  records  the  fact  that  the  student 
is  taking  a  exclusive  course  of  the  course 
s/he  is  enrolling.  If  such  a  course  is 
found,  return  false,  return  true  otherwise.  */ 
if  enrol-tuple  “=  nothing  then  f  <-  false; 

end 

end  exc^E^C^LUSION-COURSE-TAKEN  (st:s,cl:[  c,sem,s#  ’  ); 


The  second  condition  is  similar  to  no-excluded-cour se? .  All  prere¬ 
quisite  courses  are  checked  to  see  if  the  student  has  taken  each  and 
passed  (i.e.,  received  at  least  a  D+) .  Otherwise,  an  exception  is 
raised . 
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prereq  took-preq?  on  (UNDERGRAD-STUDENT, COURSE) .. enrol  is 

begin 

locals 

enrol-tuple;  ENROLLMENT; 
f:  BOOLEAN; 
f  <“  true  ; 

for  pc  in  PREREQ-COURSES  do 
if  pc.c  =  c  then 
begin 

enrol-tuple  <-  get-object  from 

ENROLLMENT 

with  (student  =  s  and 
course  =  pc.prec); 
if  enrol-tuple  =  nothing  or 

enrol-tuple . g  It  'd+’  then 

f  <-  false  ; 

end  end 


for  each  prereq  course  of  the  course,  check 
to  see  if  the  student  has  taken  the  course 
and  passed.  Report  false  if  there  is  one 
such  violation 


end  exc  PREREQUISITE -VIOLATION  (st:s,  cl : [ c , sem , s# ' ) ; 


V 


The  third  condition  is  a  simple  test  to  see  if  the  current  date  is 
greater  than  the  deadline  for  the  current  term.  Each  semester,  of 
course,  has  a  different  deadline.  An  instance  of  the  exception 
DEADLINE-PASSED  is  raised  if  the  deadline  is  not  met. 


prereq  before-deadline? 

on  (UNDERGRAD-STUDENT. COURSE) . .enrol  is 
(sem. term  =  'fall'  and  ^todate  <  'sep-5' 

or  sem. term  =  'spring'  and  Stodate  <  'mar-5' 
or  sem. term  =  'summer'  and  $todate  <  'jun-5); 
exc  DEADLINE-PASSED  (st:s,  cl : [ s , sem , s# ] ) ; 


The  last  condition  for  a  undergrad  student  is  that  s/he  can  take  at 
most  6  courses.  Otherwise  an  exception  TOO-MANY-COURSE  is  raised. 


prereq  too-many-cour ses? 

on  (UNDERGRAD-STUDENT, COURSE) . .enrol  i  is 

begin 

locals 

i:  INTEGER; 
i  <-  0: 

for  e  in  ENROLLMENT  do 

if  e. student  =  s  then  i  <-  i  +  1; 

end 

^  ( i  <=  5  )  ; 

end  exc  TOO-MANY-COURSES  (st:s); 

The  exceptions  EXCLUSIVE-COURSE-TAKEN,  PREREQUISITE-VIOLATION, 
DEADLINE-PASSED  and  TOO-MANY-COURSES  are  defined  to  be  specializations 
of  ENROL-VIOLATION. 


exception  EXCEPTION-COURSE-TAKEN  is-a  ENROL-VIOLATION; 
exception  PREREQUISITE-VIOLATION  is-a  ENROL-VIOLATION; 
exception  DEADLINE-PASSED  is-a  ENROL-VIOLATION; 
exception  TOO-MANY-COURSES  is-a  ENROL-VIOLATION; 

Assume  that  the  policy  of  handling  the  violation  of  deadline  and 


Design  and  Verification  of  IISs  Using  TAXIS 


65 


Chapter  4  IIS  Design 


exclusive  courses  is  through  petitioning,  the  following  refines  the 
handler  ENROL-HANDLER,  which  is  a  complex  property  of  REGISTER  and 
exception  ENROL-VIOLATION . 


action  pet i tion-to-college 

on  (REGISTER. . enrol-loop, DEADLINE-PASSED) .. eh  is 
PETITION ( except ion . St ,  exception. cl) ; 

Assume  that  the  policy  of  handling  the  violation  of  prerequisite 
courses  and  maximum  number  of  courses  is  that,  if  the  student  has 
grade  average  over  90,  then  let  him/her  take  the  course. 


action  sharp-student  on  (REGISTER. . enrol-loop. 

PREREQUISITE-VIOLATION) . .eh  is 

begin 

if  except ion . St . grade-average  >=  90  then 

print  '^let  him/her  take  the  course'; 

end 


By  the  inheritance  rule,  the  action  of  handling  a  TOO-MANY-COURSES 
exception  involves  printing  a  message  indicating  a  constraint  viola¬ 
tion  and  also,  a  message  pointing  out  that  the  student  is  a  good  stu¬ 
dent  and  s/he  is  allowed  to  take  the  course. 


4.^.2 .  UNDERGRADUATE-STUDENT  Enrolled  in  GRADUATE-COURSE 

For  this  combination,  assume  that  the  regulations  of  the  univer¬ 
sity  only  allow  third  year  and  fourth  year  students  to  take  graduate 
courses  and  also  the  level  of  the  courses  should  be  below  the  1500 
series.  Again,  the  two  constraints  can  be  modelled  as  additional 
prerequisites  of  the  enrol  operation  property  associated  with 
UNDERGRAD-STUDENT  and  GRADUATE-COURSE.  Note  that  since  GRADUATE- 
COURSE  is  a  specialization  of  COURSE,  the  enrol  operation  for 
UNDERGRAD-STUDENT  and  GRADUATE-COURSE  inherits  all  the  properties  of 
the  enrol  operation  for  UNDERGRAD-STUDENT  and  COURSE. 

The  first  constraint  is  simply  a  check  on  the  year  attribute  of 
the  student.  If  it  is  less  than  three,  then  an  exception  called  NOT- 
FOR-KIDS  is  raised. 

prereq  at-leas t-3 rd-year ?  on  (UNDERGRAD-STUDENT, GRADUATE- 

COURSE)  ..  enrol  is 

s.year  >=  3  exc  NOT-FOR-KIDS  (st:s,  cl:  [s,sem,s#  ]); 

The  second  constraint  is  similar  to  the  first  -  a  check  to  see  if  the 
course  number  is  below  1500.  Exception  GRAD-ONLY  is  raised  if  nega¬ 
tive  . 
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prereq  below-1500? 

on  (UNDERGRAD-STUDENT, GRADUATE-COURSE) . .enrol  is 
c. course#  <  1500 

exc  GRAD-ONLY  (st:s,cl:[  s,sem,s#  ]); 

Assume  that  the  last  two  exceptions  require  the  same  treatment, 
namely,  the  handler  will  abort.  The  actions  property  of  ENROL-HANDLER 
associated  with  NOT-FOR-KIDS  (GRAD-ONLY)  is  set  to  be  the  statement 

abort. 

action  on  (REGISTER. . enrol-loop,  NOT-FOR-KIDS) .. eh  is  abort 

4.4.3.  GRADUATE-STUDENT  Enrolled  in  COURSE 

A  graduate  student  usually  has  fewer  constraints  to  observe. 
Here  the  only  condition  is  that  s/he  has  to  enrol  in  the  course  in 
time . 


prereq  before-deadline? 

on  (GRADUATE-STUDENT, COURSE) . .enrol  is 
(sem.term  =  'fall'  and  ^todate  <  'nov-1'  or 

sem.term  =  'spring'  and  Stodate  <  'mar-1'  or 
sem.term  =  'summer'  and  $todate  <  'july-1') 
exc  DEADLINE-PASSED  (st:s); 


Note  that  a  graduate  student  has  a  later  deadline  than  an  undergradu¬ 
ate  student. 


graduate-student  Enrolled  in  UNDERGRADUATE-COURSE 

For  this  particular  combination,  assume  that  a  graduate  student 
can  only  take  4th  year  courses.  This  amounts  to  check  that  the  course 
number  is  equal  to  or  greater  than  400. 


prereq  senior-course?  on  (GRADUATE-STUDENT, 

UNDERGRAD-COURSE) . .enrol  is 

c. course#  >=  400 

exc  UNDERGRAD-ONLY  (st:s,cl:[  c,sem,s#  ]); 


Extensions  of  REGISTER 

Next,  we  will  extend  the  REGISTER  transaction.  First,  let  us 
assume  that  undergraduate  students  must  take  all  the  corequisite 
courses  of  every  course  s/he  is  taking.  The  check  is  performed  in  the 
result  part  of  REGISTER,  because  it  is  not  easy  to  find  out  beforehand 
(i.e.,  in  the  prerequisite  section  of  ENROL  and  REGISTER)  in  which 
courses  the  student  is  going  to  enrol  successfully.  Since  REGISTER  is 
defined  to  be  a  property  of  STUDENT,  we  can  associate  this  constraint 
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to  the  register  property  of  UNDERGRAD-STUDENT.  If  a  required  core¬ 
quisite  course  is  found  which  is  not  enrolled  by  the  student,  the 
exception  COREQUISITE -VIOLATION  is  raised. 


result  taking-corequiste?  on  UNDERGRAD-STUDENT. . r eg  is ter 

begin 

locals 


f  <- 
for 


f:  BOOLEAN; 

enrol- tuple:  ENROLLMENT; 
true  ; 

cl  in  class-list  do 
for  cc  in  COREQ-COURSES  do 

if  cc.c  =  cl. course  then 
begin 

enrol-tuple  <- 

get-ob3ect  from  ENROLLMENT 
with  (course  =  cc.coreqc 
and  student  =  st): 
if  enrol-tuple  =  nothing  then 

f  <-  false  ; 

end 

end 


end 

/*  For  each  class  in  class-list,  check  to  see 
every  corequisite  course  is  being  taken. 

If  not,  increment  the  variable  i.  If  i  is 
found  to  be  not  equal  to  0,  there  must  be 
a  violation  of  corequisite  courses. 

(f)  i 

end  exc  COREQUISITE -VIOLATION  (st:s,  cl : [ s , sem , s# ] ) 


is 


if 

V 


The  exception  COREQUISITE-VIOLATION  is  defined  to  be  a  specialization 
of  REGISTER-VIOLATION,  which  in  turn  is  defined  to  be  a  specialization 
of  SEMANTIC-CONSTRAINT-VIOLATION. 


exception  COREQUISITE-VIOLATION  is-a  REGISTER-VIOLATION; 


exception  REGISTER-VIOLATION  is-a  SEMANTIC-CONSTRAINT-VIOLATION 
with 

r-attr s 

St : STUDENT; 

cl : RELATION-CLASS ; 

end 


Assume  that  the  exception  handler,  called  REGISTER-HANDLER,  is  invoked 
in  case  a  REGISTER-VIOLATION  exception  is  raised.  We  can  define 
REGISTER- HANDLER  to  be  the  complex  property  value  of  ANY-EXPRESSION 
and  REGISTER-VIOLATION. 


exc-handler  eh  on  ANY-EXPRESSION , REGISTER-VIOLATION  is 

REGISTER-HANDLER; 

The  basic  action  of  REGISTER-HANDLER  is  simply  print  a  warning  message 
that  the  student  has  not  satisfied  all  the  constraints. 
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transaction  REGISTER-HANDLER  is-a  ANY-EXCEPTION-HANDLER  with 

?arams  (exception) ; 

OCfl  Is 

exception:  REGISTER-VIOLATION; 
actions 

pr int-messaqe : 

print  ^student  '  exception. st  'fails  to 

satisfy  all  register  constraints'; 

end 


We  have  completed  extending  this  level  of  specialized  enrollments. 
Note  that  the  ENROL  transaction  has  been  extended  four  times  and  thus 
induces  an  ISA  hierarchy  among  them.  Hence  a  call  of  the  form 
enrol (x,y, z,w)  will  invoke  the  most  specialized  version  of  ENROL 
depending  on  the  classes  that  x  and  y  belong  to.  The  REGISTER  tran¬ 
saction,  the  exception  handlers  ENROL-HANDLER  and  REGISTER-HANDLER 
have  all  been  specialized  several  times.  The  diagram  in  Fig.  4.3  sum¬ 
marizes  all  the  specializations  performed  in  this  level  as  well  as  the 
relationships  between  the  classes.  It  should  be  obvious  by  now  that 
the  extensions  can  be  done  by  considering  each  case  independently. 
The  programmer  has  to  be  careful  to  pick  the  correct  names  of  the  pro¬ 
perties  s/he  wants  to  define  or  redefine.  That  is,  s/he  has  to  know 
exactly  which  properties  are  inherited  and  which  properties  are  newly 
defined . 


£.5.  Yet  Another  Level 

This  level  is  similar  to  the  previous  one  in  that  we  consider 
more  new  kinds  of  students.  They  are  full-time,  part-time  of  under¬ 
graduate  and  graduate  students. 

relation  FT-UNDERGRAD-STUDENT  is-a  UNDERGRAD-STUDENT  with 
r-attrs  ,  , 

status:  1  'full-time'  }; 

end 

relation  FT-GRADUATE-STUDENT  is-a  GRADUATE-STUDENT  with 
r-attrs  , ,  , . 

status:  {|  'full-time'  |}; 

end 

Assume  that  part-time  students  have  two  more  properties:  the  number  of 
courses  taken  and  number  of  years  left  before  they  must  finish  the 
degree.  Also  that  part-time  graduate  students  can  only  be  in  the  mas¬ 
ters  program. 
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relation  PT-UNDERGRAD-STUDENT  is-a  UNDERGRAD-STUDENT  with 
r-attrs 


end 


status :  { , 

number -courses : 
year s-lef t : 


' part-time ' 
1  :  :30 
1  :  :9  I 


relation  PT-GRADUATE-STUDENT  is-a  GRADUATE-STUDENT  with 
r-attrs 

status:  ' 

program:  ' 

number-courses : 
years-left:  { 

end 


4.5.1.  PT-STUDENT  Enrolled  in  COURSE 


Assume  that  part-time  students  can  only  take  at  most  3  (2  for 
graduate  students) .  This  constraint  can  be  modelled  by  specializing 
the  prerequisite  too-many-cour ses?  of  the  enrol  property  for  PT- 
UNDERGRAD-STUDENT  and  COURSE. 


prereq  too-many-cour ses? 

on  (PT-UNDERGRAD-STUDENT, COURSE) . .enrol  is 

begin 

locals 

i:  INTEGER; 
i  <-  0: 

for  e  in  ENROLLMENT  do 

if  e. student  =  s  then  i  <-  i  +  1; 

end 

(  i  <=  3  )  ; 

end 


Similar  refinement  is  performed  on  the  too-many-cour ses?  prerequisite 
of  the  enrol  property  for  PT-GRADUATE-STUDENT  and  COURSE.  Note  that 
the  exception  TOO-MANY-COURSES  is  raised  in  case  these  prerequisites 
fail  (by  the  inheritance  rule),  hence  it  will  be  handled  by  the  same 
handler . 

The  invocation  of  enrol (x , y , z , w)  involves  more  complicated 
searching  by  the  system,  but  the  process  of  selecting  an  ENROL  tran¬ 
saction  of  use  is  the  same  as  discussed  previously. 


4.5.2.  More  Extensions  of  REGISTER 


Assume  that  full-time  undergraduate  students  must  take  at  least 
four  courses;  part-time  undergraduate  students  at  least  two  and 
finally  part-time  graduate  students  at  least  one.  These  constraints 
are  modelled  as  result  properties  on  the  student's  register  property, 
for  a  similar  reason  that  the  course  corequisite  checking  is  performed 
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in  the  result  part  of  REGISTER. 


result  take-enough-courses? 

on  FT-UNDERGRAD-STUDENT. . register  is 

begin 

locals 

i:  INTEGER; 
i  <-  0: 

for  e  in  ENROLLMENT  do 

if  e. student  =  st  then  i  <-  i  +  1; 

end 

(  i  >=  4  )  ; 

end  exc  NOT-ENOUGH-COURSES  (st:st,cl:  class-list); 

Similar  result  properties  can  be  defined  for  the  register  property  of 
PT-UNDERGRAD-STUDENT  and  PT-GRADUATE-STUDENT.  The  exception  NOT- 
ENOUGH-COURSES  is  defined  to  be  a  specialization  of  REGISTER- 
VIOLATION. 

exception  NOT-ENOUGH-COURSES  is-a  REGISTER-VIOLATION; 

Assume  that  the  policy  of  handling  NOT-ENOUGH-COURSES  is  to  print 
a  message.  The  exception  handler  of  REGISTER-VIOLATION  is  refined;  in 
particular,  the  action  property  print-message  is  refined  to  print  a 
more  specific  message. 


action  print-message 

on  (ANY-EXPRESSION,NOT-ENOUGH-COURSES) . .eh  is 
print  'student  '  exception. st  'is  not  taking  enough  courses'; 


4^.6.  Remarks 

This  completes  our  example  IIS  design.  As  illustrated  in  the 
example,  modelling  in  TAXIS  is  a  specialization  activity  which  is  car¬ 
ried  out  in  a  top-down  manner.  Modifications  of  a  TAXIS  model  are 
easy  as  long  as  they  take  place  at  the  bottom  of  the  ISA  hierarchy. 
Other  modifications  higher  up  on  the  ISA  hierarchy  may  have  global 
side-effects  and  ought  to  be  discouraged.  We  will  come  back  to  this 
system  design  in  Chapter  Eight. 
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Figures  of  Chapter  4 
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5.1.  Introduction 


This  chapter  provides  a  denotational  semantics  (hereafter  DS)  for 


TAXIS. 


By  far  the  most  important  among  the  constructs  of  TAXIS  is  the 
IS-A  relationship  and  the  way  it  is  used  to  provide  a  new  organiza¬ 
tional  principle  (abstraction  mechanism)  for  a  programming  language. 
The  importance  within  the  language  and  its  close  relation  to  set- 
theoretic  containment  (in  fact,  IS-A  has  often  been  identified  with 
the  subset  relation)  make  DS  a  suitable  vehicle  for  the  formalization 
of  TAXIS. 

Section  5.2  describes  the  general  methodology  of  DS  and  how  we 
propose  to  apply  it  to  TAXIS.  It  also  introduces  the  notation  that  is 
used  throughout  the  chapter.  Sections  5.3,  5.4  and  5.5  define  TAXIS 
program  interpretations.  Section  5.6  establishes  some  important  pro¬ 
perties  of  TAXIS.  Section  5.7  treats  certain  features  of  TAXIS, 
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particularly  exceptions  and  exception  handling,  in  terms  of  syntactic 
mappings  which  express  such  features  in  terms  of  other  constructs. 


2*?-*  Methodology 

Following  Mathematical  Logic,  we  provide  a  DS  by  defining  map¬ 
pings  from  syntactic  constructs  into  their  "meanings”. 


Semantic-Function:  Syntactic-Object  — > 


Meaning 


Syntactic  objects  are  denoted  by  syntactic  variables  of  a  given 
syntactic  category,  e.g.  i:  Identifier  defines  i  as  a  syntactic  vari¬ 
able  of  type  Identifier. 


"Meanings"  are  expressed  in  terms  of  entities,  sets 
and  functions  over  entities.  The  aim  of  this  chapter  is 
framework  for  mapping  every  TAXIS  program  P  into  a  triple 


of  entities 
to  provide  a 


(Ep,  Sp,  Tp) 


such  that 

All  identifiers  in  P  refer  to  entities  or  functions  over  enti¬ 
ties  in  Ep,  the  collection  of  entities ; 

All  program  states  for  P  are  mapped  onto  elements  of  Sp,  the 
collection  of  states ; 

All  state  transformations  defined  in  P  are  mapped  onto  state 
transformations  in  Tp,  the  collection  of  state  transformations . 


The  semantic  mapping  is  defined  in  two  steps.  First,  a  semantic 
mapping  is  defined  from  every  program  written  in  TAXIS',  a  subset  of 
TAXIS,  to  its  interpretation.  TAXIS'  does  not  include  exceptions  and 
exception  handling,  and  relational  statements  (i.e.  retrieve,  delete 
and  replace) .  Also,  TAXIS'  doesn't  offer  a  number  of  other  notational 
conveniences  available  in  TAXIS,  including  inheritance  of  properties 
by  classes.  Definition  of  the  DS  for  TAXIS  is  then  completed  by  pro¬ 
viding  a  syntactic  mapping  from  any  program  written  in  TAXIS  into  one 
written  in  TAXIS ' . 

If  P  is  a  TAXIS  (or  TAXIS')  program,  we  call  the  triple  (Ep,  Sp, 
Tp)  the  interpretation  of  P.  When  there  is  no  danger  of  confusion,  we 
omit  the  subscript  p  from  the  components  of  an  interpretation. 
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The  semantic  mapping  from  TAXIS'  programs  to  their  denotation  is 
given  in  terms  of  four  functions:  Den,  H,  F  and  G.  Den  maps  every 
token,  class,  metaclass  and  property  of  a  TAXIS'  program  into  its 
denotation,  an  entity  in  E.  H  assigns  a  value  to  every  expression  in 
a  state.  F  associates  a  state  transformation  function  to  every  tran¬ 
saction  class.  Finally,  G  defines  the  semantics  of  a  statement  in 
terms  of  a  function,  like  F. 

An  important  aspect  of  the  DS  proposed  is  the  set  of  semantic 
constraints  defined  for  any  well-formed  interpretation.  A  TAXIS  pro¬ 
gram  is  semantically  well-formed  if  and  only  if  its  interpretation  is 
well-formed. 

We  turn  now  to  the  notation  that  is  used  throughout  the  paper. 
If  A,  B  and  C  are  sets,  P-set(A)  denotes  the  power  set  of  A,  A  — >  B 
denotes  the  set  of  all  (possibly  partial)  functions  from  A  to  B,  and  f 
:  A  — >  B  is  equivalent  to  f  mb-of  A  — >  B  (mb-of  is  read  ' is  a 
member  of).  The  operator  — >  is  assumed  to  be  right  associative, 
i.e.,  A  — >  B  — >  C  is  equivalent  to  A  — >  (B  — >  C) . 

Parentheses  are  also  omitted  from  functional  expressions  when 
there  is  no  danger  of  confusion.  Thus  fx  is  equivalent  to  f(x)  if  f 
is  a  function  of  one  argument,  and  gfx  is  equivalent  to  g(f(x))  if 
both  g  and  f  are  one-argument  functions.  Functional  composition  is 
denoted  by  @.  Thus  g@f  denotes  the  function  obtained  from  f  and  g  by 
first  applying  f  and  then  g. 

X  denotes  a  vector  with  components  xl ,  ...,  xn  for  some  n  >=  1. 
If  n  =  1,  X  =  (xl)  is  treated  as  equivalent  to  xl .  If  x  =  (xl,...,xn) 
then  length  (x)  =  n.  To  make  typing  easier,  x  is  usually  taken  to  be 
X.  It  is  straightforward  to  give  more  general  denotational  semantic 
rules  involving  x. 

If  A  is  a  set,  A*n  denotes  the  set  of  all  n-tuples  over  A,  while 
K(A)  the  set  of  all  m-tuples  m  =  1,  2,  ...  over  A.  K*(A)  denotes  the 
set  of  all  n-tuples  whose  components  may  themselves  be  m-tuples  for 
some  m,  n  >  0. 

The  lambda  notation  is  used  to  define  functions  that  are  part  of 
an  interpretation.  Thus 

f  =  Lambda (x,y) . x+sq (y) 
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defines  f  as  a  function  of  two  arguments  whose  value  is  the  sum  of  the 
first  argument  and  the  square  of  the  second.  Ident(A)  denotes  the 
identity  function  over  set  A. 

Two  possibly  partial  n-ary  functions  g,  h 

g,h:  A1  X  A2  X  .  .  .  X  An  — >  B 

are  functionally  equivalent,  g  =  h,  iff  for  all  a  such  that  ai  mb-of 
Ai,  1  <=  i  <=  n,  either  both  g(a)  and  h(a)  are  undefined  or  g(a)  = 

h  (a)  . 

The  partial  functions  are  functionally  weakly  equivalent ,  g  =w  h 
iff  for  any  a  such  that  ai  mb-of  Ai,  1  <=  i  <=  n,  if  both  g(a)  and 
h(a)  are  defined,  g(a)  =  h(a).  Thus,  for  functional  equivalence  the 
two  functions  must  be  defined  for  the  same  combinations  of  arguments 
but  this  need  not  be  the  case  for  functionally  weak  equivalence. 

To  indicate  two  functions  h  and  g  are  equal  everywhere  except  at 
a  point  X,  we  use  the  notation 

X 

h  ===  g. 


_5  .^.  Entities 

The  entity  collection  E  includes  a  denotation  for  every  token, 
class,  metaclass  and  property  of  a  TAXIS'  program.  The  semantic  func¬ 
tion  Den  maps  TAXIS  symbols  into  their  denotations. 

^.^.1.  The  Structure  of  E 

Let  N  denote  the  set  of  natural  numbers,  W  the  set  of  strings,  R 
a  linearly  ordered  infinite  set  of  entities  that  are  used  as  denota¬ 
tions  for  relational  tuple  tokens,  and  J[  ,  the  denotation  of  nothing. 

Every  entity  collection  of  E  is  defined  by  a  4-tuple: 

(D,  C,  P,  i) 

where 

D  is  the  domain  of  tokens,  and 

D  =  NUWURU  (_[} 

C  is  the  collection  of  class  entities.  C  contains  one  entity  for  each 
class  (  class  entity)  and  one  entity  for  each  metaclass  (  meta¬ 
class  entity) .  Thus  C  can  be  partitioned  into 
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C  =  CC  U  CM 

where  CC  contains  all  class  entities  and  CM  all  metaclass  enti¬ 
ties.  The  entities  OC  and  1C  are  used  as  denotations  to  the 
built-in  classes  NONE  and  ANY  respectively.  CM  contains  two  spe¬ 
cial  entities  OM  and  IM  to  be  used  as  denotations  to  the  built-in 
metaclasses  NONE-CLASS  and  ANY-CLASS  respectively. 

P  is  the  collection  of  property  entities.  P  contains  one  entity  for 
each  definitional  property. 

5.^.^.  DS  for  Tokens ,  Classes  and  Metaclasses 

The  denotations  for  tokens,  classes  and  metaclasses  are  provided 
by  the  semantic  function  Den. 

The  rules  which  define  Den  for  tokens  are  as  follows: 

(a)  For  n:  Number,  num  mb-of  N,  the  number  that  corresponds  to  the 
numeral  n 

Den(n)  =  num 

(b)  For  s:  Atom,  str  mb-of  W,  the  string  that  corresponds  to  the 
atom  s 

Den(s)  =  str 

(c)  For  [  il : tl ,  ...,  in:tn  ]  :  Aggregate-token 

Den([  il:tl,  ...,  in;tn])  =  (Den(tl),  ...,  Den(tn)) 

(d)  If  i  :=  t  where  i:  Identifier,  t:  Token,  then 

Den(i)  =  Den(t) 

(e)  If  i  ;=  j,  where  i,  j:  Identifier,  then 

Den(i)  =  Den(j) 

(f)  The  token  nothing  receives  J_  as  its  denotation 

Den  (nothing)  = 

Turning  to  classes  and  metaclasses,  let  C*  and  M*  denote  respec¬ 
tively  the  collections  of  syntactic  class  and  metaclass  definitions 
constituting  a  program.  The  sets  CC  and  CM  are  isomorphisms  of  C*  and 
M*  respectively; 
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MC:  C*  — >  CC 
MM:  M*  — >  CM 

and  M  =  MC  U  MM. 

During  the  definition  of  a  TAXIS  program,  identifiers  are  associ¬ 
ated  permanently  with  classes  during  a  class  definition,  e.g. 

PERSON-TYPE  PERSON  with 
end 

where  PERSON  is  associated  with  the  class  defined  between  with  ,  and 
end  ,  or  through  a  permanent  assignment  with  a  simple  class  definition 
on  its  rhs,  e.g. 

MY-CHILDREN  :=  {|  'john',  'maria'  |} 

Let  f  denote  the  syntactic  mapping  from  identifiers  to  class 
definitions  defined  by  such  associations,  i.e. 

f:  Identifier  — >  C*  U  M* 

For  any  i:  Identifier  such  that  f(i)  is  defined. 

Den  (i)  =  M(f (i) ) 

It  is  assumed  that  Den  maps  the  built-in  metaclasses  and  classes 
as  follows: 

Den  (ANY)  =  1C 
Den (NONE)  =  OC 
Den (ANY-CLASS)  =  IM 
Den (NONE-CLASS)  =  OM 

^.3.3^.  DS  for  the  ^-A  Relationship 

Let  <<0  be  a  binary  relation  over  C  defined  as  follows: 

(a)  If  c  mb-of  C*  U  M*  has  the  form 

something  a  is-a  al ,  ...,  an  with 
end 

then  M(c)  <<0  Den(aj)  for  1  <=  j  <=  n. 

(b)  If  c  mb-of  C*  U  M*  has  the  form 
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something  a  with 
end 

then  M(c)  <<0  1C  if  c  is  a  class  and  M{c)  <<0  IM  if  c  is  a  meta¬ 
class. 

(c)  For  expressions  and  statements,  which  never  have  their  own 

class  definitions,  if  T,  T'  are  transaction  classes  and  T. .p  =  E, 
T'..p  =  E'  and  Den(T)  <<0  Den(T')f  then  Den(E)  <<0  Den(E')* 

Let  <<  be  defined  as  the  transitive  closure  of  <<0.  The  semantics  of 
the  TAXIS  predicate  is-a  can  now  be  defined  by 

Den(is-a)  =  << 

Let  p-value  be  a  function  defined  as 
p-value  :  C  x  P  — >  C  and 

p-value (c,  p)  refers  to  the  class  which  is  the  value  of  the  defini¬ 
tional  property  p  of  c.  The  semantics  of  the  ' . . '  operator  can  be 
given  by 

Den ( . . )  =  p-value 

_5._4.  States 

By  a  state  we  mean,  intuitively,  a  program  state.  Formally,  a 
state  is  defined  by  associating  to  every  variable,  class,  metaclass 
and  property  an  extension  which  describes  in  the  case  of  classes  and 
metaclasses  their  set  of  instances,  in  the  case  of  properties  a  par¬ 
tial  function  and  in  the  case  of  variables  tokens. 

5.^.1.  Definition  of  S 

For  reasons  that  will  become  apparent  shortly,  we  introduce  the 
notion  of  primitive  state  before  describing  states. 

A  primitive  state  sig  in  S  is  defined  by  a  3-tuple 

(v,  vp,  mem) 

where 

v:  variables  — >  D  U  C 

and  v(t)  where  t  is  either  a  token  or  class  variable,  returns  the 
value  (a  token  or  a  class  entity)  of  the  variable  in  state  sig. 
vp:  (D  U  C)  X  P  — >  D 

and  vp(t,  p) ,  where  t  is  a  token  or  class  entity,  gives  the  value  of 
the  factual  property  p  of  t  in  state  sig.  Sometimes  we  will  use  the 
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notation  sig(pi)(k)  to  mean  vp(k,  pi), 
mem  C  p-set(D  x  C) 

and  (t,c)  mb-of  mem  if  t  is  a  member  of  the  extension  of  c  in  state 
sig . 

Entities  in  C,  P  and  R  are  undistinguishable  from  each  other  in 
every  respect  except  for  the  ways  they  are  treated  by  functions  and 
relations.  Accordingly,  we  introduce  an  equivalence  relation  between 
primitive  states  which  holds  whenever  two  states  are  undistinguishable 
up  to  permutations  of  elements  of  R.  In  other  words,  two  primitive 
states  are  equivalent  if  there  exists  an  isomorphism  between  C,  P  and 
R  that  maintain  the  functions  vp,  v  and  relation  mem. 

More  precisely,  two  primitive  states  si  =  (vl,  vpl ,  meml )  and  s2 
=  (v2 ,  vp2 ,  mem2 )  are  Rename-equivalent,  R-equ(sl,  s2 )  (or  si  R-equ 

s2 )  iff  there  exists  an  isomorphism 

b  :  R  U  C  U  P  — >  R  U  C  U  P  (of  appropriate  sort) 

such  that 

(a)  for  any  t  mb-of  R,  c  mb-of  C 

t  meml  c  iff  b(t)  mem2  b(c) 

(b)  for  any  p  mb-of  P,  tl ,  t2  mb-of  R  or  C 

vpl(t2,  p)  =  tl  iff  vp2(b(t2),  p)  =  b(tl) 

(c)  for  any  x  mb-of  variables,  t  mb-of  R 

vl(x)  =t  iff  v2(x)  =  b(t) 

A  state  s  is  an  equivalence  class  of  SO  wrt  R-equ  where  SO  is  a 
collection  of  primitive  states.  If  SO/R-equ  denotes  the  set  of  such 
equivalence  classes, 

S  =  SO/R-equ 

All  set-theoretic  relations  for  states  can  be  redefined  to  hold 
modulo  Rename-equivalence.  Thus  two  states  si,  s2  are  equal  modulo 
R-equ,  si  =/R-equ  s2 ,  iff  si  R-equ  s2 ;  si  is  a  subset  of  s2  modulo  R- 
equ ,  si  C  /R-equ  s2  iff  there  exists  state  s3  such  that  si  R-equ  s3  C 
s2 .  Similar  definitions  can  be  given  for  all  other  set-theoretic 
relations . 

Two  semantic  constraints  are  introduced  next.  The  first,  called 
Structural  IS-A  constraint,  places  restrictions  on  the  definitional 
properties  of  TAXIS  classes. 

Structural  ^-A  Constraint :  Given  cl,  c2  and  dl  mb-of  C  and  p 
mb-of  P,  if  p-value(cl,  p)  =  c2  and  dl  <<  cl,  then  there  exists  a  d2 
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in  C  such  that  p-value(dl,  p)  =  d2  and  d2  <<  c2 ,  d2  ^  cl . 

According  to  this  semantic  constraint,  if  a  certain  class  (or 
combination  of  classes)  has  a  certain  property  p,  then  any  specializa¬ 
tion  of  the  class  (or  combination  of  classes)  has  a  property  which  is 
a  specialization  of  p. 

The  second  constraint,  called  Extensional  IS-A  Constraint  is 
instrumental  in  associating  with  <<  the  characteristics  of  what  we 
intuitively  understand  as  generalization.  The  constraint  basically 
states  that  if  class  entity  cl  is  <<-related  to  some  other  class 
entity  c2 ,  then  the  extension  of  cl  in  any  state  s  is  a  subset  of  the 
extension  of  c2 . 

We  say  that  for  any  dl ,  d2  mb-of  C,  P-ext(dl,  d2 )  holds  iff  for 
all  s  =  (v,  vp,  mem)  and  any  token  t,  t  mem  dl  =>  t  mem  d2 . 

Extensional  IS-A  Constraint;  For  all  dl ,  d2  mb-of  C,  if  dl  <<  d2 , 
then  P-ext(dl,  d2 ) . 

5.^.^.  Extens ions  of  Classes  and  Metaclasses 

Let  ext  be  a  function  defined  as 
ext  ;  C  X  S  — >  P-set(D  U  C)  so  that 
ext(x,s)  =  {t|  t  mem  cl.  Several  built-in 
extensions  which  are  independent  of  the 
defined.  Thus  for  any  s  mb-of  S 

ext(lC,s)  =  D 
ext(0C,s)  = 

ext (Den (NUMBER) ,s)  =  N 
ext (Den (ATOM) ,s)  =  W 
ext (Den (AGGREGATE -TOKEN) ,s)  =  k(D) 

Since  the  extensions  of  the  built-in  classes  are  invariant  in  all 
states,  we  will  omit  the  state  argument  in  the  ext  function  for  the 
built-in  classes. 

The  extension  of  the  AGGREGATE  classes  is  the  cross  product  of 
the  extensions  of  their  components.  Thus,  if  class  C  has  attribute 
properties  pi,  . . . ,  pn  which  have  respectively  p-values  cl,  ...,  cn, 
where  ,  ci  mb-of  C*,  then 

ext(Den(c))  =  ext(Den(cl))  X  ...  X  ext(Den(cn)) 


classes  have  standard 
state  wrt  which  they  are 
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Scalar  classes  have  state-invariant  extensions  too.  Thus,  if 

c :  =  {  I  tl ,  .  .  .  ,  tm  I } 

Then  for  all  s  mb-of  S 

ext(Den(c))  =  {Den(tl)  Den(tm)  } 


Similarly,  if 

c:=  {|  til  :  :  tl2  ,  t21::t22,  ...,  tnl::tn2  p 
then  for  all  s  mb-of  S 


ext(M(c))  =  {e|  e  mb-of  Dd  and  Den(til) 

Den(le)  e  Den(le)  Den(ti2)  for  some  1  <=  i  <=  n  } 

Den(le)  is  the  denotation  of  the  lexicographic  <=  relation 
defined  over  the  instances  of  every  scalar  class  during  its  defini¬ 
tion. 


Test-defined  classes  (TD-classes)  are  special  in  that  their 
extensions  for  any  state  s  are  defined  by  a  transaction  associated 
with  each  TD-class  through  a  property  labelled  ’test’.  Thus,  if  c  is 
a  TD-class  (i.e.  an  instance  of  the  metaclass  TD-CLASS-TYPE)  then 

ext(c)  =  {e|e  mb-of  D  and  p-value(e,  'test')(s,  e)  =  true} 

Turning  to  metaclasses,  their  extensions  are  state  invariant.  In 
particular,  for  all  states  s 

(a)  ext(lM)  =  CC  ; 

(b)  ext(OM)  =  {} 

(c)  If  a  class  definition  c  mb-of  C*  has  the  form 

CLASS-TYPE  a  is-a  some-class 
end 

where  CLASS-TYPE  denotes  a  metaclass,  then 

M(c)  mb-of  ext (Den (CLASS-TYPE) ) 

Moreover,  if  c  mb-of  M  and  Den (CLASS-TYPE)  <<  d,  then 

M(c)  mb-of  ext(d) 

The  last  part  of  rule(c)  guarantees  that  the  IS-A  constraint  for 
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extensions  is  satisfied  by  metaclasses  at  all  times. 

The  semantics  of  the  TAXIS  predicate  is  which  tests  whether  an 
object  is  an  instance  of  a  class  can  now  be  given  as  follows: 

Den (is)  =  ext 

DS  for  Built-in  Functions  and  Predicates 

Den  defines  a  denotation  for  built-in  functions  and  predicates 
such  as  +,  substr  ,  =,  <=,  ...  in  the  obvious  way. 


5.£.£.  Augmenting  the  DS  for  Expressions 

The  semantic  function  Den  defines  a  denotation  of  sorts,  for  each 
token  and  class  in  terms  of  entities.  However,  for  expression 
classes,  the  values  returned  by  the  expressions  are  a  very  important 
aspect  of  the  meaning  of  the  expressions.  Let  H  be  a  function  defined 
as 

H  :  E  — >  S  — >  CUD 

where  E  is  the  collection  of  (syntactic)  expression  classes.  H(e)s 
returns  the  value  of  e  in  state  s. 

Below,  H  is  defined  recursively. 

El.  H(nil)  =  Lambda  (s)  J_ 

E2 .  for  t  :  Token,  a  constant, 

H(t)  =  Lambda(s)  Den(t) 

E3 .  For  t  =  [  il:El,  ...,  in:En] , 

H(t)  =  [Den(il) :H(E1) ,  ...,  Den ( in) : H (En) ] 

E4.  For  a  token  or  class  variable  x 

H(x)  =  Lambda (s)  s(x) 

E5.  H( (E) )  =  H(E) 

E6 .  for  any  n-ary  operator  op 

H(op(El,  ...,  En) )  =  Den(op)  (H(E1),  ...,  H(En)) 

The  definition  of  H  will  be  used  in  the  next  section  when  we  for¬ 
malize  the  concept  of  state  transformation  in  TAXIS. 
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5._5.  State  Transformations 

This  section  is  concerned  with  the  DS  of  TAXIS  statements  and  the 
functional  component  of  DS  for  transactions.  In  TAXIS,  statements  may 
have  side-effects,  when  executed.  The  allowable  state  transformation 
schemata  are  first  presented,  then  DS  for  transactions  and  statements. 

^.^.1.  Definition  of  T 

There  are  three  primitive  state  transformation  schemata  which 
cause  respectively  the  insertion  or  deletion  of  an  entity  from  the 
extension  of  a  class  entity,  or  the  update  of  a  (r-attr ibute)  property 
of  an  entity. 

The  collection  of  state  transformation  is  defined  by  first, 
presently  three  primitive  state  transformation  schemata  and  then 
describing  how  new  primitive  transformations  can  be  formed. 

Each  state  transformation  t  can  be  treated  as  a  (partial)  func¬ 
tion  over  the  set  S  of  all  possible  consistent  states. 

t:  S  — >  S 

such  that  t(s)  =  s'  iff  t  transforms  s  to  s'. 

(a)  Insertion  Transformation  Schema 

Such  transformations  insert  a  new  token  in  the  extension  of  a 
class  and  define  its  factual  properties  to  be  undefined.  We  use  the 
notation 

insert(c) 

to  refer  to  the  token  insertion  transformation  which  inserts  a  'new' 
token  entity  in  class  c  and  all  of  c's  generalizations.  More  for¬ 
mally,  let  p-value(c,  il )  =  cl ,  . . . ,  p-value(c,  in)  =  cn  be  the  only 

definitional  properties  of  c  and  c  1C,  then  if  insert(c)s  =  s', 

where  s  =  (v,  vp,  mem)  and  s'  =  (v',  vp' ,  mem'),  then  there  exists  a 

least  element  in  R,  call  it  a,  such  that 

(1)  a  mem  c''  =>  c'  =  1C 

(2)  for  all  c'  mb-of  C  such  that  c  <<  c',  a  mem'  c' 

(3)  vp(a,  ij)  =  J[  for  1  <=  j  <=  n 

Note  that  a  token  insertion  is  a  (partial)  function  over  states 
only  because  the  identity  of  tokens  is  unimportant  in  determining 
equality  of  states. 

(b)  Deletion  Transformation  Schema 
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Such  a  transformation  removes  a  token  a  from  the  extensions  of 
all  classes  except  for  1C  and  is  denoted  delete (a).  The  transforma¬ 
tion  is  only  applicable  to  states  where  t  is  an  instance  of  a  class 
other  than  1C  and  there  is  no  factual  property  of  the  form  t.i  =  a  for 
some  t  mb-of  D  U  C.  More  precisely,  for  state  s,  delete (a) (s)  is 
defined  iff 

(1)  for  some  c  mb-of  C  c  ~=  1C,  a  mem  c, 

(2)  there  exists  no  factual  property  i  and  token  t,  t.i  =  a. 

When  these  conditions  are  satisfied,  and  delete(a)(s)  =  s',  where  s'  = 
(v',  vp' ,  mem'),  then 

(1)  if  a  mem'  c',  c'  mb-of  C,  then  c'  =  1C 

(2)  for  all  factual  properties  of  a,  vp' (a,  p)  =  1C. 

(c)  Property  Update  Transformation  Schema 

This  type  of  transformation  changes  the  factual  property  value  of 
a  tuple  token.  For  a  state  s,  update (a , i , b) ,  the  transformation  that 
changes  the  value  of  the  "i"  property  of  a  to  b,  is  defined  iff  for 
all  definitional  properties  of  c,  p-value(c,  i)  =  c',  such  that  a  mb- 
of  c,  b  mb-of  c',  a.i  ~=  b  in  s.  When  this  condition  is  satisfied,  if 
update ( a , i , b) ( s)  =  s',  then  vp'(a,i)  =  b 

To  define  the  collection  of  state  transformations  T  we  basically 
want  to  consider  the  closure  of  primitive  state  transformations  under 
composition,  iteration  and  a  form  of  conditional.  First,  however,  we 
need  some  additional  notation:  Consider  the  composition  of  two  primi¬ 
tive  transformations 

t  =def  delete (a) @ insert (c) 

where  @  denotes  the  composition  operator.  There  is  no  information 
here  on  whether  a  is,  in  fact,  the  entity,  x,  inserted  in  the  exten¬ 
sion  of  c  or  not,  even  though  the  meaning  of  t  is  quite  different 
depending  on  whether  a  is  x  or  not.  Accordingly,  we  introduce  nota¬ 
tion  which  allows  us  to  distinguish  between  the  two  cases: 

insert (c[x])  indicates  that  x  is  the  new  element  of  the  extension  of 

c . 

Let  t  =  tl@t2@...@tn  where  ti,  1  <=  i  <=  n,  are  primitive 
transformations.  We  say  that  t  is  an  open  segment  wrt  x  if  tn  = 
insert(c[x])  for  some  c  mb-of  CC  and  it  is  not  the  case  that  ti  = 

delete(x),  for  any  i,  1  <=  i  <  n.  Thus  an  open  segment  wrt  x  begins 
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by  inserting  x  in  some  class  extension  and  then  proceeds  with  other 
side-effects  which  do  not  involve  deleting  x.  A  closed  segment,  on 
the  other  hand,  involves  not  only  an  insertion  but  also  a  deletion  of 

X. 

The  collection  of  state  transformations  T  is  now  defined  as  fol¬ 
lows: 

(a)  T  includes  all  primitive  state  transformations  and  the  iden¬ 
tity  transformation  Ident(S). 

(b)  If  t  mb-of  T  and 

(i)  t  does  not  contain  an  open  or  closed  segment  wrt  x,  then 
insert (c [x] ) @t  mb-of  T 

(ii)  t  does  not  contain  a  primitive  deletion  delete(x),  then 
delete {x)@t  mb-of  T 

(iii)  tl  is  any  update  transformation,  tl@t  mb-of  T. 

(c)  If  tl ,  t2  mb-of  T  and  B  is  some  Boolean  conditions  on  states, 
then 

tl  (s)  if  B(s)  =1 

t  ( s)  = 

t2 (s)  otherwise 
is  also  a  transformation  in  T. 

(d)  Let  eta  be  a  mapping  from  finite  sets  of  entities  to  state 
transformations 

eta:  A  — >  T 

where  A  C  Dd  U  C.  Then  comp,  the  multiple  composition  operator 
is  defined  by 

comp(A,  eta(e))  =def  eta (el ) @eta (e2 ) @ . . . @eta (en) 

where  A  =  {  el,...,en}  and  e  mb-of  A.  Given  the  definition  of 
comp,  if  eta(e)  mb-of  T  for  all  e  mb-of  A,  so  is  compCA,  eta(e), 
provided  that  each  composition  satisfies  the  rules  described  in 
(b). 

Note  that  in  order  for  comp(A,  eta(e))  to  be  a  function,  it 
must  be  that  eta ( e i ) @eta ( e j ) =  eta (e j ) @eta (ei)  for  all  ei,  ej  mb- 
of  A.  We  will  assume  that  this  condition  holds  whenever  comp  is 
used. 

(e)  Nothing  else  is  in  T. 
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An  important  subset  of  T  is  the  collection  of  linear  state 
transformations  T’  whose  elements  satisfy  case  (a)  or  (b)  of  the 
definition  of  T.  Linear  state  transformations,  according  to  this 
definition,  are  primitive  state  transformations  or  composite  ones 
obtained  from  primitives  by  applying  a  fixed  number  of  composition 
operations. 

Augmenting  the  PS  for  Statements 

The  important  property  of  a  TAXIS  statement  is  the  state 
transformation  it  can  cause.  In  this  section,  the  DS  is  augmented  by 
providing  state  transformation  rules  for  the  TAXIS  statements. 

Let's  define  a  function  G  as 

G  :  ST  — >  S  X  S 

where  ST  is  the  collection  of  (syntactic)  statement  types  such  that 

G(t)s  =  s'  means  that  t  causes  the  state  transformation  from  s  to 
s'.  Below  we  will  define  G  recursively.  It  is  assumed  that  s  =  (v, 
vp,  mem)  and  s'  =  (v',  vp' ,  mem').  G  does  not  check  the  validity  of 
the  initial  or  the  final  state. 

Tl .  Assume  that  c  has  definitional  properties  pi,  1  <=  i  <=  n 
G( insert  x  in  c)s  =  s'  where 

X , mem , vp 

s‘  ==========  s 

s'(x)  =  min{ji  j  '^mem  ANy]  ,  say  k 
and  mem'  =  mem  U  {  (k,  c')  |  Den(c)  ''<c'} 
and 

(k ,pl) , . . . , (k ,pn) 
vp ' ===================  vp  and 

vp'  (k ,  pi)  =  _[ 

T2 .  Assume  that  the  token  variable  x  has  factual  properties  pi,  1  <= 
i  <=  n, 

G(delete  x) s  =  s'  where  s(x)  =  k  and 
mem, vp 

s'  =======  s  and 

mem'  =  mem  -  { (k,c) ]  all  classes  c] 
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( f  pi  )  r  •  •  •  r  r  pn  ) 

vp'  =================  vp  and 

vp'(kfPi)  =  J_  for  1  <=  i  <=  n 

T3 .  G(w.p  <-  e) s  =  s'  where 
vp 

s'  ====  s  and 
.  (H(w)s,p) 

vp*  =========  vp, 

vp' (H(w) s,p)  =  H(e) s 
T4 .  G(x  <-  e) s  =  s'  where 

X 

s'  ===  s 
s  '  (x)  =  H  (e)  s 

T5.  G(Sl;S2)s  =  G(S2)@G(Sl)s 

T6 .  G (nil) s  =  s 

T7 .  G{abort)s  =  undefined 

T8 .  G(if  b  then  SI  else  S2 ) s  =  s'  where 

G(Sl)s  if  H(b)s  is  true 

s '  = 

G (S2 ) s  otherwise 
T9.  G (while  b  do  S) s 

G(while  b  do  S)@G(S)s  if  H(b)s  is  true 
s  otherwise 

TIO.  G(for  y  in  c  do  S  end)  s  =  s' 

Let  kl ,  k2 ,  .../  kn  be  the  elements  such  that  ki  mem  c  in  s  (for 
convenience,  assume  that  they  are  increasing  order). 

We  will  define  states  si,  ...,  s(n+l),  sll ,  s21,  ...,  snl  as  fol¬ 
lows  .  Le t  s  =  si , 


II 

>1ll 

II 

1 — 1 

if) 

si 

and 

sll  (y)  =  kl , 

s2  =  G(S) sll 

s21  ==  = 

• 

s2 

and 

s21(y)  =  k2. 

s3  =  G(S)  s21 

• 

• 

V 

snl  === 

sn 

and 

snl ( y)  =  kn , 

s  (n+1 )  =  G  (S)  snl 

and  s '  =  s (n+1 )  . 
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It  is  assumed  that  in  all  the  states  mentioned  above,  Lambda(t).t 
mem  c  does  not  change.  Also,  one  may  want  to  assume  that  the  order  of 
computation  is  not  important. 

Til.  G (begin  SI, *52  end) s  =  G (begin  S2  end)@G(Sl)s 

T12 .  G (begin  end) s  =  s 

T13.  Gdocal  x;  S)s  =  G(S)s' 

X 

s  ===  s' 

S  '  (X)  =  J_ 

T14.  G(T(  E;  U  ))s  =  F(T)(  E,  U)  s 

where  U  is  a  set  of  distinct  variable  names  which  do  not  occur  in  E,  a 
set  of  expressions.  The  meaning  of  transaction  definition  is  defined 
by  the  function  F  and  is  presented  in  the  next  section. 

T15.  G(  get-object  x  from  C  with  pi: el,  ...,  pn:en)s  =  s' 

X 

v'  ===  V  and 

v'(x)  =  k  if  there  is  a  unique  k  s.t.  k  mem  C  and  vp(k,pi)  = 
H(e)s,  _L  otherwise  for  1  <=  i  <=  n. 

5.^.^.  Augmenting  the  PS  for  Transactions 

The  semantic  function  Den  defines  a  denotation,  of  sorts,  for 
each  transaction  class  in  terms  of  a  class  entity.  An  important 
aspect  of  a  transaction  meaning  concerns  its  parameters  and  possible 
state  transformations  it  causes.  This  section  provides  a  way  to  aug¬ 
ment  the  DS  for  the  meaning  of  transaction  classes. 

The  transactions  considered  in  this  section  are  assumed  to  have 
no  prerequisite  or  result  properties.  In  section  5.7  it  is  shown  how 
to  reduce  through  syntactic  transformations  any  transaction  to  one 
without  prerequisites  or  results.  The  main  reason  for  treating  prere¬ 
quisites  and  results  syntactically  is  the  difficulty  of  accounting  for 
exceptions  and  exception-handling  in  terms  of  the  DS  framework 
described  here. 

Let  F  be  a  function  defined  as 
F  :  C*T  — >  K(C  U  D)  — >  S  x  S 

where  C*T  is  the  collection  of  transaction  class  definitions.  Let  t 
mb-of  C*T  have  the  form 
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transaction  t  with  params  (v;x); 

S  — 

end 

then 

F(t)  =  Lambda (e;  u)  Lambda (s) G (S<H (e) s/v,  u/x>)s 


5.6.  The  Behavioral  Constraint  for  Expressions  and  Statements 

We  have  already  presented  the  IS-A  constraint  for  extensions 
which  limits  the  possible  extensions  a  class,  metaclass  or  property 
entity  e  can  have,  given  that  it  is  a  specialization  of  some  other 
entity  e',  e  <<  e'.  However,  expressions  and  statements  always  have 
empty  extensions  so  the  IS-A  constraint  for  extensions  does  not  con¬ 
straint  at  all  the  IS-A  relationship  for  expressions  and  statements. 
This  section  addresses  this  problem  and  proposes  conditions  that  must 
be  satisfied  if  an  expression  or  statements  declared  to  be  a  speciali¬ 
zation  of  another. 

^.^.1 .  The  ^-A  constraint  for  Expressions 

This  constraint  is  defined  differently  for  Boolean  expressions 
and  other  expressions.  In  either  case,  the  binary  predicate  P-exp  is 
used  to  test  whether  two  expressions  satisfy  the  IS-A  constraint,  i.e 
if  el,  e2  are  expression  class  entities  which  satisfy  the  IS-A  con¬ 
straint,  then  P-exp(el,  e2 )  is  true. 

^.6.1.1.  Boolean  Expressions 

If  el,  e2  are  expression  class  entities  such  that  el  <<  e2  then 
it  must  be  that  H(el)s  =  1  implies  that  H(e2)s  =  1  for  all  s  mb-of  S. 

According  to  this,  the  IS-A  constraint  for  Boolean  expressions 
amounts  to  logical  implication.  If  the  reader  expected  a  set- 
theoretic  formulation  of  the  constraint,  he  may  prefer  the  following 
equivalent  formulation:  Let 

B:  Boolean-Expressions  — >  P-set(S) 

defined  by 

B(BOOL)  =  (s|H(BOOL)s  =  1^ 
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Then  if  Den(Bl)  <<  Den (B2 )  it  must  be  that  B(B1)  C  B(B2). 

Other  Expressions 

Let  <<*  be  =D  U  <<,  where  =D  is  the  equality  relation  defined 
over  D.  The  IS-A  constraint  for  non-Boolean  expressions  states  that 
if  el  <<  e2  and  H(el)s  is  defined  then  it  must  be  that  H(el)s  <<* 
H(e2) s. 

It  follows  from  this  that  for  expressions  which  have  tokens  as 
values,  the  IS-A  constraint  for  expressions  states  that  when  H(el)s  is 
defined,  H(e2)s  must  also  be  defined  and  moreover  H(el)s  =D  H(e2)s. 
On  the  other  hand,  for  expressions  which  have  classes  or  metaclasses 
as  entities,  equality  is  replaced  with  <<. 

5.6.^.  The  IS-A  Constraint  for  Statements 

The  IS-A  constraint  for  state  transformations  is  formulated  in 
terms  of  the  notion  of  'net  side-effect'.  A  side-effect  is  caused 
either  by  the  insertion  of  an  entity  in  the  extension  of  a  class 
entity  or  the  deletion  of  one  from  the  extension  of  a  class  entity,  or 
the  update  of  a  factual  property.  Accordingly,  we  will  use  the  fol¬ 
lowing  notation: 

(a)  The  side-effect  caused  by  the  insertion  of  an  entity  x  in  the 
class  entity  c  is  denoted  [c(x)]. 

(b)  The  side-effect  caused  by  the  deletion  of  an  entity  x  is 
denoted  [-x] . 

(c)  The  side-effect  caused  by  update (a , i , b)  is  denoted  [a,i,b]. 

Let  V  denote  the  set  of  all  possible  side-effects.  It  is  possible  to 
associate  with  every  element  of  T' ,  the  set  of  linear  state  transfor¬ 
mations  (see  section  5.5.1),  a  set  of  net  side-effects  through  the 
function 

side-effects;  T'  — >  P-set(V) 

such  that 

(a)  side-ef f ects ( Ident (S) )  =  {} 

(b)  side-ef f ects (insert (c [x] ) @t)  = 

side-ef f ects ( t)  U  {lc'(x)]|  for  all  c'  such  that  c  <<  c'} 

U  {[x,i,J^]  I  for  all  definitional  properties  i  of  c} 

(c)  side-effects (delete (x) @t)  = 

side-ef fects ( t)  -  |[c(x)]|  c  mb-of  c) 
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-  { [  y  ,  i ,  d] I  X  is  a  component  of  y  ) 
if  [c(x)]  mb-of  side-ef f ects ( t)  for  some  c  mb-of  C 

side-ef fects ( t)  -  { [y,i,d] |  x  is  a  component  of  y  } 

U  [-x]  otherwise 

(d)  side-effects (update (a, i,b) @t)  = 

side-effects (t)  U  {[a,i,b]}  -  {[ari,c]|c  b,  c  mb-of  d} 
These  definitions  are  intended  to  make  side-ef fects ( t)  a  descrip¬ 
tion  of  the  'net'  side-effects  caused  by  a  linear  state  transformation 
t.  For  example,  if  an  entity  is  inserted  in  the  extension  of  a  class 
and  is  subsequently  removed  there  is  no  net  side-effect.  Similarly, 
if  the  p-value  of  a  factual  property  is  changed  several  times,  the  net 
side-effect  (i.e  the  side-effect  that  is  visible  after  the  application 
of  the  transformation)  is  the  last  update  only. 

Evidence  that  indeed  side-ef fects ( t)  describes  the  net  side- 
effects  caused  by  t  is  provided  by  the  following  theorems. 

Theorem  If  ts  =  s'  then 

(1)  [c(x)]  mb-of  side-ef fects ( t)  iff  x  mem  c'  =>  c'  =  1C  and  x 
mem'  c. 

(2)  [-x]  mb-of  side-ef  fects  ( t)  iff  x  mem  c'  ~=>  c'  =  1C  and  x  mem' 
c '  =>  c '  =  1C 

(3)  if  vp(a,i)  ~=  b  then  [a,i,b]  mb-of  side-ef fects { t)  iff 
vp' (a, i)  =  b 

Theorem  For  any  s,  t  mb-of  T', 

side-ef fects ( s)  =  side-ef fects ( t)  iff  s  =w  t 

The  proofs  of  these  theorems  appear  in  appendix  D.  Theorem 
5.6.2 .2  is  particularly  important  because  it  establishes  that  the  set 
of  net  side-effects  associated  with  a  linear  state  transformation 
characterizes  it  completely  as  far  as  its  functional  characteristics 
are  concerned. 

The  definitions  presented  above  cannot  be  applied  directly  to 
arbitrary  elements  of  T  since  conditionals  and  multiple  compositions 
make  the  set  of  net  side-effects  caused  by  a  transformation  t  depen¬ 
dent  on  the  state  it  is  applied.  For  example. 

Lambda (s) insert (c)  if  Bs  =  1 
Ident(S)  otherwise 
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has  different  net  side-effects  depending  on  whether  it  is  applied  to  a 
state  where  B  holds. 

However,  it  is  possible  to  define  a  mapping  which  essentially 
linearizes  a  transformation  t  for  each  state  s: 

lin:  T  X  S  — >  T' 


such  that 

(a)  If  t  is  a  primitive  transformation  then 

t  if  ts  is  defined 

lin(t,  s)  = 

undefined  otherwise 

(b)  If  t  =  tl@t2  then 


lin(t,  s)  =  lin(tl,  t2s)@lin(t2,  s) 


(c) 


If 


then 


Lambda ( s) tl ( s)  if  B(s)  =  1 

t  = 

Lambda (s) t2 ( s)  otherwise 
tl  if  B(s)  =  1 

lin(t,  s)  = 

t2  otherwise 


(d) 


If 

t  =  comp(A(s) ,eta (e) ) 

,  where  A(s)  is  a  set  of  entities  that  depends  on  s  and 
A ( s) ,  then 


e  mb-of 


lin(t,  s)  =  eta (el ) @eta {e2 ) @ . . . @eta (en) 

where  el,  ...,  en  are  all  the  entities  in  A(s)  arranged  in  some  arbi¬ 
trary  order. 

The  IS-A  constraint  for  statements  can  now  be  expressed  as  fol¬ 
lows:  If  SI,  S2  are  statement  class  entities  such  that  SI  <<  S2  then 
it  must  be  the  case  that  for  all  s  mb-of  S  such  that  G(Sl)s  is 
defined , 

s ide-ef f ects ( 1 in (G (S2 ) ,  s) )  C  side-ef fects { lin (G (SI ) ,  s) ) 

In  other  words,  if  SI  <<  S2 ,  then  SI  must  cause  at  least  the  net 
side-effects  of  S2  and  possibly  more.  Moreover,  the  net  side-effects 
of  SI  must  not  cancel  out  any  of  the  net  side-effects  of  S2 .  If  they 
did,  there  would  be  an  element  of  side-ef feet (lin (G (S2 ) ,  s) )  which  is 
not  in  side-ef feet ( lin (G (SI ) ,  s) ) .  We  let  P-s  be  a  binary  predicate 
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over  statement  class  entities  which  is  true  for  two  entities  SI,  S2 
iff  they  satisfy  the  IS-A  constraint  for  statements. 

Given  two  statement  class  entities  SI,  S2 ,  we  can  now  define  the 
Behavioural  IS-A  Constraint  for  statements  in  terms  of  P-s: 

Behavioural  IS-A  Constraint  for  Statements  :  If  SI  <<  S2  where 
SI,  S2  are  statement  class  entities  then  it  must  be  that  P-s(Sl,S2). 

P-s  can  be  thought  of  as  analogous  to  P-ext  in  the  sense  that  it  for¬ 
malizes  conditions  that  must  be  satisfied  if  an  statement  class  is 
defined  as  a  specialization  of  another  statement  class. 

Some  Implications  of  the  IS-A  Constraint  for  Statements 

This  section  points  out  some  of  the  implications  of  the  defini¬ 
tions  given  earlier.  In  particular,  a  relationship  is  established 
between  the  structure  of  a  statement  and  its  behaviour.  By  structure 
we  mean  the  component  substatements  of  a  statement.  For  example,  the 
structure  of  a  conditional  includes  its  Boolean  condition  and  its  then 
and  else  parts,  the  structure  of  a  while  statement  includes  its 
Boolean  expression  and  its  body,  and  the  structure  of  a  transaction 
call  includes  its  argument  expressions  and  the  statements  constituting 
the  body  of  the  transaction.  By  behaviour  of  an  expression  we  mean 
the  functions  it  is  mapped  onto  by  G. 

Before  we  present  the  main  results  of  the  section  we  need  some 
definitions.  If  t,  q  mb-of  T,  we  say  that  t  is  an  independent  con¬ 
tinuation  of  q  if  for  all  s  mb-of  S  such  that  t@qs  is  defined 

side-effects ( lin (q, s) )  C  side-effects (lin (t@q,s) ) 

According  to  this  definition,  an  independent  continuation  of  s  does 
not  cancel  out  any  of  the  net  side-effects  caused  by  s. 

In  TAXIS,  a  class  Cl  is  a  specialization  of  another  class  C2  if 
it  is  located  below  C2  on  the  IS-A  hierarchy  of  classes.  The  notion 
of  specialization  can  be  stretched  to  apply  to  state  transformations 
as  well:  f  tl ,  t2  mb-of  T,  tl  is  a  specialization  of  t2  iff  for  all  s 
mb-of  S 

side-ef fects ( 1 in ( t2 , s) )  C  side-ef f ects ( 1 in ( tl , s) ) 

The  reasons  for  stretching  the  notion  of  specialization  in  this  manner 
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should  be  obvious  to  the  reader:  If  a  statement  class  SI  is  a  special¬ 
ization  of  another  S2 ,  then  by  the  IS-A  Constraint  for  statements 

side-effects (lin (G (S2 ), s) )  C  side-effects (lin (G (SI ) ,  s) ) 

,  i.e  G(S1)  is  a  specialization  of  G(S2). 

The  notion  of  specialization  for  state  transformations  can  be 
further  extended:  If  tl,  t2  mb-of  T  and  tl '  is  a  specialization  of  tl , 
we  say  that  tl '  is  an  independent  specialization  of  tl  wrt  t2  if  for 
all  s  mb-of  S  where  tl@t2  is  defined 

side-effects(lin(tl@t2 ,s) )  C  side-ef f ects ( lin ( tl ' @ t2 ,  s) ) 

In  other  words,  the  net  side-effects  of  tl '  which  are  not  also  net 
side-effects  of  tl  must  not  cancel  out  any  of  the  net  side-effects 
caused  by  t2 .  Since  it  is  assumed  that  tl ‘  is  a  specialization  of  tl 
as  well,  the  net  side-effects  of  tl '  cannot  cancel  any  of  the  net 
side-effects  of  tl  or  t2  when  tl '  is  a  specialization  of  tl  wrt  t2 . 

It  is  now  possible  to  state  yet  another  semantic  constraint  which 
effectively  limits  the  amount  of  interaction  between  statements  con¬ 
stituting  the  body  of  a  transaction  of  T  and  statements  constituting 
the  body  of  a  specialization  of  T. 

Let  Tl  be  a  transaction  with  prerequisite,  action  and  result 
statements  SI,  S2 ,  ...,  Sn,  to  be  evaluated  in  that  order.  Let  T2  be 
a  specialization  of  Tl  and  S  be  an  expression  in  the  body  of  T2 . 

Transaction  Constraint 

(a)  If  Den(S)  <<  Den(Si),  it  must  be  that  G(S)  is  an  independent 
specialization  of  G(Si)  wrt  G(S(i-l))  @...@G(S1) 

(b)  If  S  is  not  a  specialization  of  an  statement  in  Tl  and  it  is 
to  be  evaluated  before  Ei  and  after  E(i-l),  then  it  must  be  that  G(S) 
is  an  independent  continuation  of  G (S ( i-1 ) ) @ . . . @G (SI ) 

According  to  this  definition,  all  the  net  side-effects  of  Tl 
which  are  not  net  side-effects  of  T2  must  be  independent  (i.e  must  not 
cancel  out  any  )  of  the  net  side-effects  of  Tl .  Thus,  in  specializing 
a  transaction  we  are  only  allowed  to  have  it  do  more  things,  never 
cancel  out  things  it  is  supposed  to  do  because  of  its  position  on  the 
IS-A  hierarchy  of  transactions. 

The  above  constraint  allows  the  statement  of  the  following 
theorem: 
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Theorem  ^*6.^.1 

If  Tl,  T2  are  transaction  classes  such  that  Den(Tl),  Den(T2) 
satisfy  the  structural  IS-A  constraint  and  the  transaction  constraint, 
and  El,  ...,  En  are  arbitrary  expressions  then 

P-s (Den (Tl (El ,  ...,  En) ) ,  Den(T2(El,  ...,  En) ) ) 

The  theorem  is  shown  in  appendix  D  and  is  important  because  it 
establishes  a  logical  relationship  between  the  structural  IS-A  con¬ 
straint  and  the  transaction  constraint  on  one  hand  and  the  behavioural 
IS-A  constraint  for  statements  on  the  other. 

A  similar  logical  relationships  can  be  shown  between  the  struc¬ 
tural  IS-A  constraint  and  the  transaction  constraint  on  one  hand  and 
the  IS-A  constraint  for  transactions  on  the  other: 

If  Tl ,  T2  are  transaction  classes  such  that  Den(Tl),  Den(T2) 
satisfy  the  structural  IS-A  constraint  and  the  transaction  constraint, 
then  Den(Tl),  Den(T2)  satisfy  the  behavioural  IS-A  constraint  for 
transactions. 

If  Tl(El,  ...,  En)  is  a  specialization  of  T2(E1,  ...,  En) )  for 

any  El,  ...,  En  it  does  not  follow  that  structurally  the  first  tran¬ 
saction  is  a  specialization  of  the  second.  However,  a  transaction  can 
be  found  which  is  equivalent  to  the  first  behaviourally  and  is  spe¬ 
cialization  of  the  second  structurally.  That  is,  we  have  a  weak  con¬ 
verse  to  theorem  5. 6. 3.1: 

If  P-exp (Den (Tl (El , . . . ,  En) ) ,  Den (T2 (El , . . . ,En) ) )  for  all  El, 
...,  En  where  Tl ,  T2  are  transactions,  then  there  exists  another  tran¬ 
saction  Tl '  such  that  Tl ' ,  T2  satisfy  the  structural  IS-A  constraint 
and  F(T1)  =  F(T1 ' ) • 

Using  a  similar  proof  argument  of  theorem  5. 6. 3.1,  sufficient 
conditions  can  be  provided  for  two  composite  statements  to  establish 
P-exp.  Given  two  composite  statements  si  and  s2 ,  assume  that  we 
already  have  information  on  whether  respective  components  of  si  and  s2 
satisfy  the  IS-A  constraint  for  statements,  the  following  conditions 
will  determine  whether  P-exp (si,  s2 )  holds. 

(1)  If  B,  B'  are  Boolean  expressions,  S,  S',  S2 ,  S2 '  are  state¬ 

ments  such  that  P-exp (Den (B) ,  Den(B')),  P-exp (Den (SI ) ,  Den(Sl')), 
P-exp (Den (S2 ) ,  Den(S2'))  and  G(Si)  is  an  independent  specializa¬ 
tion  of  G(Si'),  wrt  G(Bi'),  i  =  1,  2,  then 
P-exp (Den (if  B  then  SI  else  S2 ) , 
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Den (if  B'  then  SI'  else  S2 ' ) ) 

(2)  If  G(S1)  is  an  independent  specialization  of  Gt(Sl')  wrt  Gt(B) 
then 

P-exp (Den (while  B  do  SI),  Den (while  B  do  SI')) 

(3)  If  Gt(Si)  is  an  independent  specialization  of  Gt(Si')  wrt 
Gt(Si-l')@. . Gt(Sl')  for  1  <=  i  <=  n  then 

P-exp (Den (begin  SI;  S2 ;  Sn  end). 

Den (begin  SI';...;  Sn'  end)) 

(4)  If  G(S)  is  an  independent  continuation  of  G (Si) @ . . . @G (SI )  then 
P-exp (Den (begin  SI;...;  Si;  S;  S(i+1);  ...;  Sn  end). 

Den (begin  end)) 

(5)  If  P-exp (Den (SI ) ,  Den(S2))  then 

P-exp (Den (for  x  in  C  do  SI),  Den (for  x  in  C  do  S2 ) ) 

Like  its  predecessors  in  this  section,  these  properties  establish 
yet  another  relationship  between  the  structural  and  behavioural  IS-A 
constraints. 


^ * Z *  Syntactic  Transformations 

This  section  is  dedicated  to  the  description  of  syntactic 
transformations  that  map  arbitrary  TAXIS  programs  onto  TAXIS'  ones. 

For  the  purposes  of  this  section,  a  TAXIS  program  P  is  a  4-tuple 

(C*(P)  UM*(P),  f(P),  PE(P),  is-a(P)*) 

where 

C*(P)  is  the  set  of  all  class  definitions  for  P 

M*(P)  is  the  set  of  all  metaclass  definitions  for  P 

f(P)  is  a  mapping  that  assigns  permanent  names  to  classes  and 

metaclasses: 

f(P):  Identifier  — >  C*(P)  U  M*(P) 

PE(P)  C  K(C*(P)  U  M*(P),  Identifier,  C*(P)  U  M*(P))  is  the  set  of  all 
properties  in  P 

is-a(P)*  C  C*(P)  X  C*(P)  U  M*(P)  X  M*(P)  is  the  binary  relation  over 
class  and  metaclass  corresponding  to  the  predicate. 

Given  a  program  P,  C*(P)  contains  one  element  for  each  class 
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definition,  simple  (e.g.  [|  'john',  'mary'  |]),  built-in  (e.g.  ANY)  or 

otherwise.  A  similar  comment  applies  for  M*(P)  and  metaclasses. 
f{P)  was  already  discussed  in  section  5.3.2. 

PE(P)  is  defined  as  follows: 

(a)  For  each  simple  property  i:  D  in  the  definition  of  a  class  C, 
(C,  i,  D)  is  added  to  PE(P) 

(b)  For  each  complex  property  with  subjects  Cl,  ...,  Cn,  attribute 
i  and  p-value  D,  ((Cl,  ...,  Cn) ,  i,  D)  is  added  to  PE(P). 

(c)  If  (xl,  ...,  xn)  is  the  parameter  list  of  transaction  T,  where 
xl:Cl,  ...,  XnrCn  are  simple  properties  of  T.  ((Cl,  ...,  Cn, 
parameter-list,  T)  is  added  to  PE(P). 

(d)  If  k:(al,  ...,  am)  is  a  key  property  of  an  IDD  class  D  where 
al:Cl,  ...,  am:Cm  are  simple  (attribute)  properties  of  D  then 
((Cl,...,  Cm),  k,  D)  is  added  to  PE(P). 

(e)  If  E  exc  F  appears  as  p-value  of  a  prerequisite  or  result  pro¬ 
perty  of  a  transaction,  (E,  exception,  F)  is  added  to  PE(P). 

(f)  If  (  E  exc-handler  for  F  is  H)  appears  as  p-value  of  a  prere¬ 
quisite,  action  or  result  property  then  ( (E.  F) ,  exc-handler  H) 
is  added  to  PE (P) . 

Finally,  (Cl,  C2 )  mb-of  iff  Cl  J^-a  C2 . 

It  must  be  noted  that  the  above  characterization  of  a  program  P 
is  not  meant  to  be  complete  and  is  only  intended  to  capture  some  use¬ 
ful  aspects  of  a  program's  syntactic  structure. 

5.2.1.  Initial  Transformation 

The  first  transformation  we  will  consider  simply  accounts  for  the 
inheritance  property  of  the  J^-a  relationship; 

SM-inh(P)  =  P' 

such  that  C*(P')  =  C*(P),  M*(P')  =  M*(P),  f(P')  =  f(P),  is-a(P’)*  = 

is-a(P)*  and  finally 

PE(P')  =  PE(P)  U  l(C,i,D)  I  there  exists  (E,i,D)  mb-of  PE(P)  and 
Cj  is-a*  E j ,  1  <=  j  <=  length (C)  and  there  is  no  class  or  metaclass  F 
such  that  (C,i,F)  mb-of  P  }. 

The  set  PE(P')  -  PE(P)  contains  all  inherited  properties  for  a 
class  or  a  collection  of  classes. 

From  now  on  when  we  talk  about  a  program  P  we  will  mean  SM- 
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inh  (P)  . 


1*Z*?-*  Insert-object 

insert-object  statement  has  the  form 
insert-object  X  in  C  with  pl:vl,  pn:vn 

To  simplify  the  denotational  rules  and  the  rule  of  inference  in  the 
next  chapter,  the  statement  is  broken  down  into  the  following  state¬ 
ments  in  TAXIS'  by  the  syntactic  mapping  function  SM-insert: 

insert-object  x  into  C; 
x.pl  <-  Vi; 
x.p2  <-  v2  ; 

• 

x.pn  <-  vn; 

Z*Z*Z*  Blocks 

If  the  last  construct  in  a  block  statement  is  an  expression  (used 
in  Chapter  Four  to  express  the  value  of  a  complex  prerequisites  and 
results)  of  the  form: 

begin 

end 

Then  the  syntactic  mapping  function  SM-blk  will  transform  the  block 
into  a  transaction  with  a  system  created  reference  parameter  to  refer 
to  the  value  of  the  expression:  The  above  block  statement  is 
transformed  into 
T(;B); 

where  T  has  the  form: 

transaction  T  with 
local  :  B 
S; 

B  <-  E; 

end 

Z  *  Z  *  £  •  in  it 

Given  a  parameter  or  local  variable  declaration  of  the  form: 
c:C  init  E; 

It  is  mapped  by  the  syntactic  transformer  SM-init  to 
c  :  C ;  c  <-  E  ; 
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5.2*5.  Exception  Handling 

Suppose  that  ((E-  F) ,  eh,  H)  mb-of  PE(P)  is  an  exception  handling 
property,  i.e  E  is  an  expression,  F  an  exception  and  H  an  exception 
handling  transaction.  Moreover,  let  Tl(El),  ...,  Tk(Ek)  be  the  tran¬ 
saction  calls  that  appear  inside  E,  then,  for  each  Ti,  1  <=  i  <=  k,  we 
define  new  transactions  TiE,  such  that  TiE  is  the  same  as  Ti  except 
that  every  prerequisite  or  result  property  pr :  B  exc  F(al:Gl,  ..., 
an:Gn)  is  replaced  by  an  action  property 

pr:  if  B  then  nil  else 
begin  local  x:F; 

insert-object  x  into  F; 
x.ai  <-  Gi  for  1  <=  i  <=  n 
H(x) 

end 

Also,  E  is  replaced  by  E'  where  Ti(Ei)  is  replaced  by  TiE(Ei),  1 
<=  i  <=  k.  Once  this  transformation  has  been  carried  out  for  all 
exception  handling  properties,  all  such  properties  and  exception  pro¬ 
perties  can  be  removed  from  PE(P).  The  result  is  a  program  P'  which 
has  no  exception  handling,  no  prerequisites  and  no  results,  but  the 
number  of  transactions  it  contains  is  approximately  equal  to  the 
number  of  transaction  calls  in  P  (or  P')* 

Note  that  in  order  to  define  this  transformation  SM-exc  we  had  to 
relax  somewhat  the  definition  of  the  insert-object  statement  to  allow 
insertions  in  an  exception  class. 

5.7.^.  Relational  Expressions 

The  semantics  of  high  level  relational  statements  are  given  in 
terms  of  syntactic  transformations.  First,  for  retrieve  statement,  a 
syntactic  mapping  SM-retr  is  defined  as  follows: 

SM-retr (  retrieve  for  xl  in  Cl , . . . ,  xn  in  Cn 
into  C(E1,  ...,  En)  where  (E) ) 

for  xl  in  Cl 

for  x2  in  C2 

for  xn  in  Cn 

if  E  then  insert-object  x  in  C; 
x.ai  <-  Ei  for  a<=i<=n 

end 

end 

end 
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where  al ,  an  are  the  attributes  and  r-attribute  properties  of  C. 

delete  and  replace  statements  are  handled  in  a  very  similar  way 
to  retrieve  ,  with  insert-object  replaced  by  remove-object  or  a  pro¬ 
perty  modification  operation. 

It  follows  from  the  definitions  of  these  mappings  that  SM-blk, 
SM-insert,  SM-init,  SM-retr,  SM-del  and  SM-repl  are  local  transforma¬ 
tions  in  the  sense  that  they  transform  a  statement  independently  of 
the  surrounding  program.  SM-exc,  on  the  other  hand,  is  global 
transformation  which  operates  on  a  complete  TAXIS  program. 

TAXIS'  programs  can  be  obtained  from  TAXIS  ones  by  applying  first 
SM-blk,  SM-insert,  SM-init,  SM-retr,  SM-del,  SM-repl  and  SM-gobj  to 
eliminate  relational  statements,  then  SM-exc  to  eliminate  exceptions, 
exception-handling  and  prerequisite  and  result  properties  of  transac¬ 
tions. 

In  the  next  chapter,  we  will  present  a  complementary  formal 
definition  of  TAXIS  through  axioms  and  rules  of  inference. 
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Table  of  Contents 


Axiomatic  Definition  of  TAXIS 

6.1  Introduction 

6.2  The  Assertion  Language 

6.3  Defining  Axioms  for  Standard  Symbols 

6.4  Axioms  for  Data  Classes 

6.5  Axioms  and  Rules  for  Statements 


6.1 . 

Introduction 


The  axioms  and  rules  of  inference  to  be  pre 
constitute  an  axiomatic  definition  of  TAXIS' 
defined  in  Chapter  Five.  Given  a  program  M  wr 
transformation  rules  listed  in  Section  5.7  will 
transfer  M  into  M'  in  TAXIS',  before  the  axioms 
to  establish  formal  properties.  The  origi 
(Hoare[69,  71])  should  provide  the  necessary 
chapter . 


sented  in  this  chapter 
,  a  subset  of  TAXIS  as 
itten  in  TAXIS,  the 
have  to  be  applied  to 
and  rules  can  be  used 
nal  papers  by  Hoare 
background  for  this 


The  Hoare-style  axiomat izat ion  of  programming  languages  involves 
the  following  subjects. 

The  assertion  language,  which  is  an  augmented  First  Order  Predi¬ 
cate  Calculus. 

A  set  of  atomic  formulae  (axioms)  in  the  assertion  language. 

A  set  of  atomic  formulae  of  the  form  pIsIq  as  axioms  where  P  and 
Q  are  assertions  in  the  assertion  language  and  S  stands  for  a 
TAXIS  statement. 

A  set  of  rules  of  inference  of  the  form 


HI  ,  . . . ,  Hn 

H 

which  is  read:  "if  Hi,  ...,  Hn  are  true  then  H  is  true",  or  of 
the  form 


HI  ;  .  . . ;Hn  | -  Hm 

H 

which  is  read:  "if  Hm  can  be  proved  assuming  that  HI,  ...,Hn  are 
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true,  then  H  is  true". 

Section  6.2  defines  the  assertion  language.  Sections  6.3  through 
6.5  give  axioms  and  rules  of  inference  for  TAXIS  standard  symbols, 
data  classes  and  statements  respectively. 

f 'The  Assertion  Language 

The  assertion  language  of  TAXIS  is  an  augmented  First  Order 
Predicate  Calculus  language  with  four  sorts  of  variables:  token, 
class,  metaclass  and  property.  The  constants  are  the  same  as  those  of 
the  programming  language  except  that  aggregate  tokens  are  not  allowed. 
The  expressions  can  be  of  types  token,  tuple,  metaclass  and  class  and 
are  the  same  as  that  of  the  programming  language.  The  usual  logical 
connectives  and  quantifiers  are  in  the  assertion  language.  Function 
symbols  include  the  arithmetic  operators,  string  operators,  the  defin¬ 
itional  property  selector  ..  and  the  following  sequences  of  symbols 
satisfying  the  syntax: 

E  :=  .  (the  factual  property  selector) 

E  :=  E[a,p,e 

where  p  is  a  property  symbol  and  a,  e  are  token  expressions. 

Predicate  symbols  include  =,  >,  <,  IS-A  and  the  following 

sequences  of  symbols  satisfying  the  syntax: 

M  :  =  is 
M  :=  M[e,c' 

M  :=  M[~e] 

where  e  is  token  expression  and  c  a  class  expression. 

The  following  symbols  will  be  used  to  denote  TAXIS  constructs. 

-  a,  b,  c,  ...  for  token  constants 

-  C,  Cl,  C2 ,  ...  for  class  constants 

-  X,  Y,  ...  for  class  variables 

-  M,  Ml,  ...  for  metaclass  variables 

-  t,  tl ,  t2 ,  ...,  for  token  variables 

-  x,  y,  ...  for  tuple  variables 

-  p,  q,  ...  for  property  variables 

The  notation  P<x/y>  where  P  is  an  assertion,  is  used  to  denote 
assertion  obtained  by  substituting  x  for  all  free  occurrences  of  y  in 
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P  with  necessary  renaming  of  bound  variables  to  avoid  name  conflict. 
The  notation  P<xl/yl,  x2/y2,  xn/yn>  denotes  simultaneous  substi¬ 

tutions  of  any  yi  by  the  corresponding  xi.  The  variables  yi  must  be 
distinct,  otherwise  the  substitution  is  not  defined.  All  free  vari¬ 
ables  are  assumed  to  be  universally  quantified. 

The  notation 
(Vx:C)  P(x) 

is  used  as  a  shorthand  for: 

(Vx) (is(x,C)  =>  P(x) ) 

Defining  Axioms  for  Standard  Symbols 

This  section  gives  defining  axioms  for  the  standard  symbols,  IS- 
A,  built-in  metaclasses  and  classes  and  the  function  E  and  predicate 

M. 

First,  the  predicate  symbol  IS-A  is  characterized  as  a  partial 
order  relation. 

Al.  IS-A(X1,  X2)  and  IS-A(X2,  X3 )  =>  IS-A(X1,  X3 ) 

A2  .  IS-A  (XI,  X2)  and  IS-A(X2,  XI)  =>  XI  =  X2 

A3.  IS-A(X,  X) 

An  additional  property  of  IS-A  is  that  a  class  contains  all  the 
instances  of  its  specializations. 

A4.  is(t,  XI)  and  IS-A(X1,  X2 )  =>  is(t,  X2 ) 

Next,  we  have  the  IS-A  constraint  on  properties  of  classes. 

A5.  IS-A  (XI,  X2)  and  X2..p  =  X3  =>  IS-A  (XI..  p  =  X3 ) 

A6 .  XI. .p  =  X2  and  is(u,Xl)  =>  [ (Ev)  (is(v,X2)  and  u.p  =  v) 

or  u.p  =  nothing 

A7.  tl.p  =  t2  =>  (EXl,  X2)  (Xl..p  =  X2  and  is(tl,Xl)  and 

(is(t2,  X2 )  or  t2  =  nothing  ))  and 

~is(t,  ANY)  =>  t.p  =  nothing  and 
nothing.p  =  nothing 

The  next  three  axioms  give  meaning  to  the  built-in  metaclasses 
and  classes. 

A8.  IS-A(NONE-CLASS,  M)  and  IS-A(M,  ANY-CLASS) 

A9.  IS-A(NONE,  X)  and  IS-A(X,  ANY) 

AlO.  ~is(X,  NONE-CLASS)  and  ~is(t,  NONE) 
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Axioms  for  Data  Classes 

First,  built-in  classes  INTEGER  and  STRING  are  defined  as: 

All.  is ( t , INTEGER)  for  any  number  t 

A12 .  is{x,  INTEGER)  =>  (x  =  1  or  x  =  2  or  . . . ) 

A13 .  is{t,  STRING)  for  any  sequence  t  of  characters  enclosed  in 
quotes . 

Given  a  TAXIS  program  M,  if  a  form-defined  class  FD  is  defined  as 
follows : 

FD  :=  Cl  @  C2  @  ...  @  Cn 

Then  FD  contains  all  and  only  those  tokens  that  are  the  concate- 


nations 

of  the 

tokens  from 

classes 

Cl, 

C2  ,  ...,  Cn. 

A14. 

is (cl , 

Cl )  and  . . . 

and  is( 

CP  9 

Cnl  ,  ,  , 

>  is (cl 

11 

c2  ]  1  ...  II  Cn,  FD) 

Given  a  TD-CLASS  instance  C,  the  predefined  property  test  of  TD- 
CLASS  determines  the  membership  of  its  instances. 

A15.  is (C, TD-CLASS)  and  is(t,  ANY)  and 

test(t,C)  =  true  =>  is{t,C) 


Given  a  relation  class  R  defined  as  the  following: 


relation  R  with 
keys 

id :  ( rl ,  r2  ,  .  .  .  ,  rm)  ; 

attrs 

rl :  Cl  total  ; 
r2  :  C2  total  ; 

•  •  • 

rm:  Cm  total  ; 
r-attrs 

•  •  • 

rn:  Cn; 

•  •  • 

end 


Firstly,  the  keyness  property  of  relation  classes  is  that  all 
instances  have  distinct  keys. 


A16.  is(tl,  R)  and  is(t2,  R)  =>  ~(tl.rl  =  t2  .  rl  and  ... 

and  tl .  rm  =  t2  .  rm) 


Secondly,  all  key  attributes  of  relation  intances  can  not  be 
equal  to  nothing 

A17.  is(t,  R)  =>  t.ri  “=  nothing  for  i  =  1,  2,  ...,  m 
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6.5.  Axioms  and  Rules  for  Statements 

In  this  section,  we  will  give  axioms  and  rules  of  inference  for 
the  TAXIS  statements  in  terms  of  primitives  p{s1q  where  P  and  Q  are 
assertions  written  in  the  assertion  language  and  S  a  TAXIS  statement. 

RO.  Rule  of  Consequence 

p|  s}t 

Rl .  Rule  of  insert-object 

(Et)  (t  "=  nothing  and  ''is(t,  ANY)  and 

,  P<is[t,C]7is,  . [t,pl , no thing*  ... [t,pn, nothing] /. ,  t/x> 

1  insert-object  x  into  Cj  P 

where  pi,  1  <=  i  <=  n,  are  the  definitional  properties  of  C. 

R2 .  Rule  of  delete-object 

P<is[7x*/is,  .[x,pl , nothing] . . . [x,pn, nothing] /.> 
i  delete  x^  P 

where  pi  are  the  same  as  in  Rl . 

R3  .  Rule  of  Property  Modification 
P<. [w,p,el /.>  {w.p  <-  e}  P 
R4 .  Rule  of  Assignment 
P<e/x>  {x  <-  el  P 

R5 .  Rule  of  Statement  Concatenation 

p{si1r,  r{S2}q 
p[s1;S2Tq 

R6 .  Rule  of  nil 
P(  nil  }P 

R7 .  Rule  of  abort 

p{  abort  ^  false 
R8 .  Rule  of  If  Statement 

P  and  B  {siIq,  P  and  ~B  {S2}q 
p{*  if  B  then  SI  else  S2Tq 

R9 .  Rule  of  while  Statement 

P  and  B  {s}  P 

P  r  while  B  do  S  end  P  and  ~B 
RIO.  Rule  of  For  Statement 

Let  A  and  B  be  classes^  the  notation  P<A//B>  means  replacing  by  A  all 
occurrences  of  B  in  " is-expressions"  (see  Section  6.2).  (In  particu¬ 
lar,  observe  that  B  is  not  replaced  by  A  in  expressions  of  the  form 
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IS-A(B,D)  or  B..p.)  Let  Z  be  a  class  variable  not  free  in  P. 

(Vt:Z)  (is(t,C))  and  is(y,  C)  and 

r  1  ,  is(y,  Z)  and  P<Z//C> 

_ 

P<NONE//C>  {  for  y  in  C  do  S  end  ]  P 


Rll.  Rules  of  Blocks 

P  {Sl^  R,  R  {  begin  S2  end  }  Q 
pT  begin  S1;S2  end  J  Q 

P  {  begin  end  ^  P 

R12  .  Rule  of  Variable  Declaration 


P<y/x>  {s}  Q<y/x> 

P  {  local  x;  s}  Q 

where  y  is  not  free  in  P  or  Q. 

R13 .  Rule  of  Transaction  Declaration 

To  express  the  formal  property  of  transaction,  predicates  are  put 
inside  the  transaction.  Given  a  transaction  declaration: 


transaction  T  with 
params 

(c;x) 

S  — 

end 

c  and  X  are  respectively  the  value  and  actual  parameters.  c  and  x 
have  to  be  distinct.  Inside  S,  no  element  in  c  can  appear  on  the  left 
side  of  any  assignment  statement  or  be  passed  as  actual  parameter  to 
another  transaction.  In  addition,  elements  in  c  can  only  be  string  or 
integer  type  parameters.  S  can  contain  no  transaction  declaration.  S 
has  access  to  classes  and  constants  which  are  defined  globally  through 
the  permanent  assignment  operator  :=. 

Let  cl ,  c2 ,  . . . ,  cn  be  the  elements  in  c  and  that  they  are 
declared  to  belong  to  classes  Cl,  C2 ,  ...,  Cn  respectively.  Simi¬ 
larly,  let  xl ,  x2 ,  ...,  xm  be  the  elements  in  x  and  that  they  are 
declared  to  belong  to  classes  Xl ,  X2 ,  ...,  Xm  respectively. 


(cl 

rCl) 

and 

i  s  ( c2  ,  C2  ) 

a  nd  ... 

and 

is (cn ,Cn) 

and 

(xl 

,X1) 

and 

i  s  ( x2  ,  X2  ) 

and  . . . 

and 

is (xm,Xm) 

and 

P  {S}  Q 


P  {  params  (c;x)  ;  S  }  Q 


R14.  Rule  of  Transaction  Call 

Assume  that  the  declaration  of  transaction  T  has  the  form  as  that 
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of  R13 .  The  following  rule  for  transaction  call  is  essentially  the 
same  rule  of  parameter  substitution  from  Cook [78'. 

P  {  params  (c;x) ;  S  }  Q 
P<e/c,  v/x>  {T(e,v)}  Q<e/c,v/x> 

provided  that  no  element  in  v  is  free  in  P  or  Q.  Variables  v  must  be 
distinct  and  have  no  occurrence  in  the  expressions  e. 

R15.  Rule  of  get-object 


[  (Ex)  ( is  (x,C)  and  x.p  =  v)  and  (Vx)(is(x,C) 

and  x.p  =  V 


or 

‘■'fS’ 


(is(x,C)  and  x.p  =  v)  =>  Q<nothing/y> ] 
<-  get-object  from  C  with  p  =  v  )  P 


=> 


Q<x/y>) ] 


where  x.p  =  v  (similarly  for  and  p  =  v)  is  a  shorthand  notation  for 
x.pl  =  vl  and  x.p2  =  v2  and  ...  and  x.pn  =  vn. 


The  correctness  of  these  rules  will  be  proven  in  the  next 
chapter.  They  will  then  be  used  to  verify  the  correctness  of  the  IIS 
designed  in  Chapter  Four. 
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Table  of  Contents 

Z*  Consistency  of  TAXIS  Formalizations 

7.1  Introduction 

7.2  Standard  Interpretation  I  of  Assertion  Language 

7.3  The  Soundness  Theorem  of  TAXIS 

Z*Z*  Introduction 

This  chapter  establishes  the  consistency  of  the  two  formal  defin¬ 
itions  of  TAXIS,  denotational  and  axiomatic  semantics.  The  purpose  is 
to  ensure  the  two  formalizations  of  TAXIS  are  not  contradictory  to 
each  other. 

In  section  7.2,  the  interpretation  of  the  assertion  language  is 
given.  Section  7.3  sets  up  the  theorem  of  soundness  and  presents  a 
selected  set  of  proofs  of  the  validity  of  the  axiomatic  definition. 

Z*?_’  Interpretation  of  Assertions  in  State  s 

The  variables,  constant  symbols,  arithmetic  operators,  string 
operators,  predicate  symbol  IS-A  and  the  function  symbol  p-value  in 
the  assertion  language  receive  the  same  interpretations  as  the  DS 
function  Den  provides  to  the  programming  language  symbols.  The 
interpretation  of  an  expression  in  the  assertion  language  in  a  state  s 
receives  the  same  treatment  as  the  DS  function  H  provides  to  the  pro¬ 
gramming  language  expressions. 

Given  a  state  s  =  (v,  vp,  mem) ,  the  special  function  E  receives 
the  following  interpretation: 
if  E  is  .  then  Es  =  vp 

if  E  =  E' [a,p,e*  then  Es  =  Lambda ( zl , z2 ). g ( zl , z2 ) 

where 

g(zl,z2)  =  if  zl  =  s(a)  and  z2=s(p)  then  H(e)s  else  E's. 

The  interpretation  of  the  special  predicate  M  in  a  state  s  is  as 
follows : 

if  M  =  is,  then  Ms  =  mem 
if  M  =  M' [a,c‘  then 

Ms  =  M's  U  I  (H(a)s,  k)  I  k  mb-of  C,  s(c)  <<  k) 
if  M  =  M' [~a]  then 
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Ms  =  M's  -  {  (H(a)s,  k)  I  k  mb-of  c] 

If  formula  P  has  free  variables  xl ,  x2  ,  xn,  then  P  expresses  a 

relation  R  as  follows:  R(  5^,  5^,  — ,  holds  true  iff  P  is  true  in 

the  standard  interpretation  I  when  its  free  variables  are  interpreted 
as  3^,  function  symbol  E  and  predicate  M  are 

interpreted  as  given  above. 

The  Soundness  Theorem  of  TAXIS 

To  prove  the  soundness  of  the  axiomatizat ion ,  we  have  to  define 
the  truth  of  formulas  of  the  form  pIsIq  in  the  denotational  model.  We 
will  use  DM[I]  to  denote  the  denotational  model  under  interpretation 

I. 

The  intuitive  meaning  of  p{s}q  is  that  if  P  is  true  under  I,  then 
after  the  execution  of  expression  S  and  if  S  halts,  Q  is  true  in  the 
final  state.  Formally, 

pfs^Q  is  true  in  DM[I' 

iff  VsVs'  [  P(s)  and  G(S)s  =  s'  =>  Q(s') 

where  G  is  the  state  transition  function  presented  in  Chapter  Five. 

Let's  call  the  proof  rules  we  have  for  the  TAXIS  subset  deductive 
system  H,  and  the  deductive  system  for  our  assertion  language  D.  A 
proof  of  formula  p(s}q  is  a  series  of  formulas  so  that  each  formula  is 
either 

an  axiom  from  H  or  D 

an  application  of  an  inference  rule  from  H  or  D  to  an  previous 
formula 

and  the  final  formula  is  p{s}q. 

We  denote  p{s1q  is  provable  if  there  is  a  proof  in  the  above  sense  by 
|-(H,D)P{S}0. 

Deductive  system  D  is  sound  relative  to  the  interpretation  I  if 
for  any  formula  P  if  | -DP  (P  is  provable  in  D)  then  P  is  true  in  I. 
If  P  is  true  for  all  interpretations  I,  then  P  is  said  to  be  valid. 
We  would  like  to  establish  the  soundness  of  H  in  a  similar  fashion, 
the  purpose  is  to  show  that  H  correctly  reflects  the  denotational 
semantics  given  in  Chapter  Five.  If  p{s1q  is  provable  in  deductive 
systems  H,  D  ( | - (H , D) P{ s} Q) ,  and  if  deductive  system  D  is  sound,  then 
deductive  system  H  is  sound  if  p{s^Q  is  true  under  DM[I' .  If  pIsIq  is 
true  for  all  denotational  models  DM[I],  then  p{s}q  is  valid.  A  rule 
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of  inference 

Hi  ,  H2  ,  .  .  .  ,  Hn 
H 

is  valid  iff  H  is  true  in  every  model  in  which  Hi,  . . . ,  Hn  are  true. 

We  are  ready  now  to  state  the  soundness  theorem. 

Theorem  7.3:  The  axioms  and  rules  of  inference  in  Chapter  Six  are 
valid. 

From  Theorem  7.3,  a  straightforward  mathematical  induction  on  the 
length  of  proofs  can  establish  the  following  result: 

Corollary:  If  D  is  sound  relative  to  I  and  | - (H,D) p{ s}q,  then  p{s}q  is 
true  in  DM[ I] . 

proof : 

The  formula  p{s}q  can  be  reached  as  a  last  step  in  a  proof  by  an 
application  of  one  of  the  axioms  or  rules  presented  in  Chapter  Six. 
By  Theorem  7.3,  each  axiom  and  rule  of  inference  is  valid  in  DM[I], 
and  by  the  induction  hypothesis  that  pIs^Q  is  true  up  to  but  before 
the  last  step,  we  have  that  p{s}q  is  true  in  DM[I]. 

For  the  rest  of  this  chapter,  we  will  prove  the  validity  of  a 
selected  subset  of  the  axioms  and  rules  of  inference  presented  in 
Chapter  Six. 

To  prove  axioms  1  to  3 ,  we  have  to  prove  the  following: 

(1)  XI  <<  X2  and  X2  <<  X3  =>  XI  «  X3 

(2)  XI  <<  X2  and  X2  <<  XI  =>  XI  =  X2 

(3)  X  <<  X 

where  X,  XI,  X2  and  X3  are  entities  in  CC  or  CM. 

Since  <<  is  defined  to  be  a  partial  order  relation  (section  5.3 
in  Chapter  Five) ,  the  proof  is  immediate. 

The  validity  proof  for  axiom  4  involves  proving  the  following: 

Vs  [  Z  mb-of  s(Xl)  and  XI  <<  X2  =>  Z  mb-of  s{X2) 

where  Z  is  an  entity  ranged  over  Dd,  Xl  and  X2  are  entities  ranged 
over  CC. 

Assume  Z  mb-of  s(Xl)  and  Xl  <<  X2,  by  the  Extensional  IS-A  Con- 


Design  and  Verification  of  IISs  Using  TAXIS 


111 


Chapter  7  Consistency  of  TAXIS  Formalizations 

straint  (section  5.4  of  Chapter  Five),  we  have  s(Xl)  C  s(X2)  for  all 
state  s,  hence  Z  mb-of  s(X2)  for  all  s. 

Very  similar  and  straightforward  arguments  can  be  given  for  these 
'static*  axioms  in  the  sense  that  no  formulas  for  the  form  p{s1q  are 
involved.  We  will  now  proceed  to  prove  the  correctness  of  the  rules 
of  those  statements  that  are  'unique'  in  TAXIS. 

Proof  of  insert-object 

(Et)  (t  “=  nothing  and  ~is(t,  ANY) 

f  and  P<is [t rCJ/is,  [ t ,pl , nothing] ...[ t ,pn , nothing] /. ,  t/x> 

1  insert-obgect  x  in  C}  P 

Assume  that 

G{  insert-object  x  in  C) s  =  s'  and  that  the  predicate  on  the  left 
of  insert-object  is  true  in  s  (denoted  by  Ihs(s)). 

[Notel :  to  prove  that  P<xl/yl,  ...,  xn/yn>s  implies  P<zl/yl,  ..., 

zn/yn>s',  it  is  sufficient  to  show  that  s  and  s'  agree  everywhere 
except  at  yl ,  ...,  yn  and  that  s(xi)  =  s'(zi).] 

[Note2 :  if  states  s  and  s'  are  Rename-equivalent  (see  Chapter  Five), 

then  for  any  predicate  P,  P(s')  <=>  P(s)  ’ 

Since  Ihs(s)  is  true,  there  exists  a  token,  say  j,  s(t)  =  j,  that 
makes  Ihs(s)  true,  in  particular,  we  know 

j  “=  i 

j  ~mb-of  1C 

s(is[t,c])  =  mem  U  { (j,K)  |  K  mb-of  C,  Den(c)  << 

s (. [t,pl , nothing] ... [t,pn, nothing] )  =  g(zl,z2) 

where 

g(zl,z2)  =  vp(zl,z2)  unless  zl  =  j,  z2=s(pi)  for  some  i  where 
g(zl,z2)=J_. 

Define  state  s'*  =  (v'',  vp' ' ,  mem'')  such  that 
x,mem, vp 

s’’  ============  s  with 

s'  ' (X)  =  j 

s' ' (mem)  =  s(mem)  U  { (j,  K)  |  K  mb-of  C,  3(c)  << 
vp' '  =  vp  except  at  (j,  pi)  where  vp''(j,pi)  =  J_ 

By  notes  above,  we  have  P(s'')  true  since 

P<is[t,c] /is,  .[t,pl,  nothing  ■...[t,pn,  nothing  V*  f  t/x>s  ir. 
assumed  to  be  true. 
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According  to  denotational  rule  T1 ,  we  have 

G(  insert...  )s  =  s'  where  s'  =  (v',  vp',  mem')  and 

s' (x)  =  k,  k  =  min{h  |  h  “mb-of  IC^ 

mem'  =  mem  U  { (k,  K)  |  K  mb-of  C  and  s(c)  << 

vp'(k,pi)  =  J[  with  vp'  =  vp  otherwise. 

Thus,  states  s''  and  s'  are  isomorphic  (mapping  j  to  k)  because  all 
functions  and  predicates  have  the  same  values  on  j  and  k,  therefore, 
s''  and  s'  are  Rename-equivalent,  hence  P(s')  is  true.  QED 

Proof  of  delete-object 

P<is[~a'/is,  .[a, pi , nothing] . . . [ a, pn, nothing] /.> 

(  delete-object  al  P 
Again,  assume  Ihs(s)  is  true,  and  that 
G(  delete-object  a) s  =  s' 

By  definition  of  is[~a', 

s(is[~a])  =  mem  -  t  (a,  K)  |  K  mb-of  c} 

and 

s (. [a , pi , nothing] ... )  =  g(zl,z2)  where  g  is  as  the  same  function 
as  above. 

But  according  to  denotational  rule  T2 , 
s' (is)  =  mem  -  ( (a,K)  |  K  mb-of  c} 

and 

vp'  =  vp  except  at  (a, pi)  where  vp'  (a, pi)  =  J^, 
and  hence  P(s')  is  true.  QED 

Proof  of  property  modification 
P<. [w,p,e] /.>  {w.p  <-  e}  P 
Assume  Ihs(s)  and  that 
G  (w.  p  <-  e)  s  =  s  ' 

By  definition  of  the  E  function 

s(.[w,p,e])  =  g(zl,z2)  where  g  =  vp  unless  zl=H(w)s  and  z2=s(p) 
where  it  is  equal  to  H(e)s.  But  this  agrees  with  denotational  rule 
T3 ,  hence  P(s')  is  true. 

QED 

Proof  of  the  for  rule  (a) 
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P  {S^  P 

P  {  for  y  in  c  do  S  end  }  P 
where  y  is  not  free  in  P. 

Assume  that 

VsVs'  (P(s)  and  G(S)s  =  s'  =>  P(s'))  and  that 
G (  for  y  in  c  do  S  end  ) s  =  s' 
and  assume  that  P(s)  is  true. 

We  will  prove  by  induction  on  the  size  of  class  c.  Define  states 
si,  s(n+l),  sll ,  snl  as  in  denotational  rule  TIO.  Also,  let 

kl ,  ...,  kn  be  the  elements  such  that  ki  mb-of  c  in  s.  Assume  that 

P(sm),  we  have  to  show  that  P(s(m+1))  is  true.  Since 

y 

sml  ===  sm  and  sml (y)  =  km  and  s(m+l)  =  G(S)sml 

Because  y  is  not  free  in  P,  P{sml)  is  true.  By  the  premise  of  the 
rule,  we  have  P(s(m+1))  true.  Therefore,  we  have  P(s(n+1))  true  in 
particular,  but  since  s{n+l)  =  s',  P(s')  is  true.  QED 

Proof  of  for  rule  (b) 

Let  Z  be  a  class  variable  not  appearing  in  P,  suppose  that 
G(  for  y  in  c  do  S  end  )s  =  s'  and 
P<NONE//c>s  is  true 

Define  states  si,  ...,  s(n+l),  sll,  ...,  snl  as  in  denotational  rule 
TlO.  New  states  tl ,  ...,  t(n+l),  til,  ...,  tnl  are  defined 

corresponding  to  si ,  ...,  sn,  s(n+l),  sll,  ...,  snl  as  follows; 


s  =  si  =  tl 
mem 

tl  =====  til  and  til (mem (h , Z) )  =  true  for  no  h  and 
t2  =  G(S)  til 
mem 

t2  =====  t21  and  t2 1  (mem  (h ,  Z )  )  =  true  for  h  =  kl  and 
t3  =  G  ( S )  t2 1 


mem 


tn  =====  tnl  and  tnl (mem (h , Z ) )  =  true  for  1  =  k(n-l),  k(n-2), 

and 

t (n+1)  =  G(S) tnl 


Observation : 
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P(ti)  <=>  P(si) 

since  S  does  not  have  Z  in  it,  the  changes  to  s(i-l)l  are  the  same  as 
to  t(i-l)l,  i.e.,  both  states  have  the  same  state  transformation 
applied  to  them,  namely,  the  execution  of  statement  S. 

Lemma  1  P<Z//c>(til)  for  1  <=  i  <=  n 

Proof  by  induction  on  the  state  sequence  til,  t2 ,  t21,  t3 ,  .... 
Basis:  P<Z//c>(tll) 

Since  P<NONE//c> ( tl )  and  Z,  y  are  not  free  in  P,  we  have 
P<NONE//c> ( til ) .  Also,  til (mem(h , Z) )  =  true  for  no  h,  so  P<Z//c>(tll) 
is  true  since  Z  and  NONE  both  have  no  elements  in  them. 

Induction:  assume  P<Z//c> ( t ( i-1 ) 1 ) 

By  the  premise  of  the  inference  rule,  we  have 
P<Z//c,  is[y,Z] /is> (ti) 

But  according  to  the  definition  of  til, 
til (mem)  =  {  (k(i-l),  Z) }  U  ti(mem) 

Since  y  =  k(i-l)  in  state  ti, 

til (mem)  =  {(y,Z)}  U  ti(mem) 

=  ti (mem [y , Z] ) 

hence 

P<Z//c>(til)  is  true. 

Lemma  2  is(a,  C) (t(n+l))  <=>  is[y:Z' (a,Z) (t(n+l)) 

proof:  By  definition  of  t(n+l), 

mem(h,Z)  =  true  for  h  =  kl ,  ...,  k(n+l)  and  y  =  kn 

and 

mem(h,  C)  =  true  for  h  =  kl ,  ...,  kn 
Therefore , 

is[y,Z] (a,Z)  in  t(n+l) 

=  true  if  a  =kl  or  a  =  k2  or  ...  or  a  =  kn 
=  is(a,c)  in  t(n+l)  (membership  of  c  never  changes) 

By  Lemma  1,  in  particular,  we  have  P<Z//c> ( tnl ) .  By  the  premise 
of  the  for  rule,  we  have 

P<Z//c,  is [y , Z] /is> ( t (n+1 ) ) 

So  f rom  P<Z//c> (s) ,  we  have  P<Z//c,  is[y,Z] /is> (t (n+1) ) .  But  then, 
since  Z  replaces  c  only  in  is  expressions  and  by  Lemma  2,  ls[y,Z  (a, 
Z)  is  true  in  t(n+l)  iff  is(a,C)  is  true  in  t(n+l).  Therefore,  all 
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is-type  predicates  in  P  maintain  exactly  the  truth  values  as  those  in 
P<Z//c,  is[y,Z]/is>,  so  P(t(n+1))  is  true.  By  Observation,  P(s(n+1)) 
is  true,  since,  s(n+l)  is  defined  to  be  s',  we  have  P(s'). 

QED 

In  the  next  chapter,  some  of  these  rules  will  be  used  to  prove 
the  IIS  designed  in  Chapter  Four  is  correct. 
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8.1.  Introduction 

The  key  concept  in  TAXIS  is  the  IS-A  relationship.  In  Chapter 
Four,  a  design  methodology  of  IIS  based  on  this  concept  has  been 
demonstrated  through  an  example.  The  idea  is  that  a  TAXIS  model  is 
designed  in  a  controlled  manner  whereby  the  designer  should  develop 
the  topmost  part  of  the  model  and  then  extend  the  model  using  the  con¬ 
cept  of  class  specialization  along  the  IS-A  hierarchies.  In  this 
chapter,  we  will  show  that  the  concept  of  IS-A  is  also  applicable  to 
the  specification  and  verification  aspects  of  TAXIS  models.  The  idea 
will  be  illustrated  via  the  same  example  in  Chapter  Four. 

An  IIS  modelled  using  TAXIS  has  transactions  that  are  mainly 
database  update  operations.  These  operations  are  characterized  by  (1) 
a  lot  of  integrity  constraint  checking  on  the  database  and  (2)  rela¬ 
tively  simple  update  activities  are  performed  on  the  database.  These 
characteristics  are  reflected  in  TAXIS' s  transactions  by  (1)  rela¬ 
tively  involved  prerequisites  and  results  and  (2)  simple  actions  part. 
Correspondingly,  the  verification  methodology  of  TAXIS  will  be  illus¬ 
trated  with  emphasis  on  the  semantic  integrity  constraint  specifica¬ 
tion  and  preservation  aspects  of  TAXIS  transactions.  Since  TAXIS  is  a 
language  primarily  intended  for  database  system  design,  verification 
of  the  preservation  of  integrity  of  the  database  is  a  very  important 
task  by  itself.  Ideas  and  results  of  this  aspect  of  system  design 
will  also  be  illustrated  in  this  chapter. 

To  make  the  presentation  in  a  manageable  fashion,  we  will  concen¬ 
trate  on  the  enrol  transaction  and  its  specializations,  also,  we  will 
assume  that  all  exception  handling  transactions  have  the  same  action, 
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namely,  abort. 

To  simplify  writing  and  proving  of  logical  statements,  free  vari¬ 
ables  are  assumed  to  be  universally  quantified,  existential  quantif¬ 
iers  are  replaced  by  constants  or  skolem  functions.  The  following 
notation  will  be  used: 

(i)  x:C 
P(x) 

to  represent  the  statement 
Vx[is(x,C)  =>  P(x)] 

(ii)  const  c:C 
P(c) 

to  represent 

Ex[is(x,C)  and  P(x)' 


(iii) 


x:C;  f (x) :D 
P(x,  fix)) 


to  represent 


VxEy  [is(x,C)  and  is(y,D)  =>  P(x,y)] 


where  f(x)  is  the  skolem  function  replacing  the  existential  quantifier 
y  which  depends  on  x. 

The  functions  add  and  drop  are  defined  as  follows:  add(c,C)  is 
the  class  C  with  token  c  inserted.  drop(c,C)  is  the  class  C  with 
token  c  removed.  Axiomat ically ,  they  are  defined  as 

is  (x, add (c ,C) )  <=>  ~is(c,C)  and  is [c,C]  (x,C) . 

is (x,drop (c,C) )  <=>  is(c,C)  and  is[~c'(x,C) 

In  any  TAXIS  program,  there  are  only  a  fixed  finite  set  of 
classes,  metaclasses  and  properties.  In  this  chapter,  we  will 
(without  any  loss  of  expressive  power)  eliminate  quantification  over 
classes,  metaclasses  and  properties,  and  therefore  class,  metaclass 
and  property  variables.  Also,  since  there  are  only  constant  property 
symbols,  expressions  of  the  form  b.[a,p,e'q  will  be  simplified  to  b.q 
while  b.[a,q,elq  will  be  simplified  to  b.q[a:e''  which  is  interpreted 
as : 

if  b=a  then  e  else  b.q. 

For  example,  we  can  rewrite  rules  Rl ,  R2  and  R3  using  our  short¬ 
hand  notation  as  follows 
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Rl '  (Et) (t  ~=  nothing  and  ~is(t,  ANY)  and 

P<add (t ,C) //C,  pi [ trnothing] /pi ,  t/x> 

I  insert-object  x  in  c}  P 

R2 ’ .  P<drop(a,C) //C,  pi [a : nothing] /pi>  {  delete-object  a  }  P 
where  C  is  any  class  constant  symbol  in  P. 

R3  '  P<p[a:e1/p>  {  a.p  <-  e  ^  P 

Given  a  database  D,  an  integrity  constraint  I  defined  on  D  speci¬ 
fies  an  invariant  condition  that  has  to  be  maintained  by  every  tran¬ 
saction  that  modifies  D.  This  notion  can  be  expressed  as  lfT}l  where 
T  is  a  transaction.  To  ensure  integrity  of  D,  this  proof  has  to  be 
carried  out  for  every  constraint  and  every  transaction.  Assuming  that 
we  have  n  constraints  and  m  transactions,  up  to  n*m  correctness  proofs 
may  have  to  be  conducted,  obviously  a  very  lengthy  and  tiring  task. 
In  what  is  to  follow,  we  will  specify  and  verify  correctness  condi¬ 
tions  in  a  layer  by  layer  fashion,  starting  at  the  general  enrollment 
level.  It  will  be  shown  that  with  IS-A  hierarchies,  it  is  easier  to 
specify  and  verify  integrity  constraints  on  a  database.  It  is  assumed 
that  all  TAXIS  semantic  constraints  (extensional ,  structural  and 
behavioral)  are  observed  on  all  TAXIS  objects  (relations  and  transac¬ 
tions)  . 

?*?-•  General  Enrollment  Level 

At  this  level,  there  are  two  constraints  to  be  maintained. 

10  erENROLLMENT:  f(e):CLASS 

e.course=f (e) .course  and  e. semester=f (e) . semester 
and  e. section#=f (e) . section# 

(for  every  enrollment  tuple,  there  exists  a  corresponding 
class  in  CLASS) 

11  c: CLASS 

c.max#  >=  c . num-of-students 

The  enrol  property  of  STUDENT  and  COURSE  is  a  transaction,  call  it  Tl . 
The  constraint  verification  at  this  level  therefore  consists  of  the 
following  proof  s :  '  I0{  Tl }  10  and  I1{t1}i1. 

After  the  syntactic  transformation  (section  5.7),  the  body 
(prerequisites,  actions  and  results)  of  Tl  has  the  form: 

1.  class-there? ( ;B) ; 

2 .  if  B  then  nil  else  abort  ; 

3.  enough-space? ( ;B) ; 
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4.  if  B  then  nil  else  abort  ; 

5.  insert-object  j  in  ENROLLMENT; 

6.  j. student  <-  s; 

7.  j. course  <-  c; 

8.  j. section#  <-  s# ; 

9.  class  <-  get-object  from  CLASS  with 

course=i . course  and  semes ter=j . semester  and 
sect ion# =1 . section# ; 

10.  class . num-of-students  <-  class , num-of-students  +  1; 


class-there?  and  enough-space?  are  transactions  that  are  created 
by  the  syntactic  transformers  of  blocks  and  exception  handling.  These 
transactions  are  as  below: 


transaction  class-there?  with 

farams  B:  BOOL  init  false 
ocals  class:  CLASS: 

class  <-  get-object  from  CLASS  with 

semester=sem  and  section#=s#  and  course=c; 
if  class  ~=  nothing  then  B  <-  true  ; 

end 


transaction  enough-space?  with 

?arams  B:  BOOL  init  false  ; 
ocals  class:  CLASS: 

class  <-  get-object  from  CLASS  with 

semester=sem  and  section#=s#  and  course=c; 
if  class. max#  >  class . num-of-students  then  B  <-  true  ; 

end 


Proof  of  I0{t1^I0 

10  will  be  driven  'backward'  using  the  rules  presented  in  Chapter 
Six.  First,  drive  10  up  to  statement  2. 

10'  {3  ;4;5;6;7;8;9;10}  10 

Using  the  rule  of  insert-object  statement  with  appropriate  simplifica¬ 
tion,  and  assuming  that  el  is  the  constant  for  the  existential  quan¬ 
tifier  Et. 

10'  e : add (el .ENROLLMENT) :  f(e):CLASS 

e . course [ el : c]  =  f(e). course 
e. semester [el : sem]  =  f (e) . semester 
e . section# [ el : s# ]  =  f (e) . section# 

Now,  if  we  can  show  that  I0{l;2}l0',  then  we  can  conclude  that 

I0{t1}i0.  Statement  1  is  a  transaction  call  to  class-there?.  Class- 

there?  has  the  following  property  which  follows  directly  from  get- 
/ 

object  inside  its  body: 

true  {  class-there?  }  B=true  =>  Q 

Q  const  class:  CLASS 

class . semes ter  =  sem  and  class. course  =  c  and 
class . sect ion#  =  s# 

Using  the  if  and  transaction  call  statements,  we  have  to  show  that 


Design  and  Verification  of  IISs  Using  TAXIS 


12  0 


Chapter  8  Verification  of  IISs 


(1)  10  and  B  {  nil  }  10' 
and 

(2)  10  and  *'B  {  abort  }  10' 

Since  abort  has  the  following  property  that 
P  (  abort  ^  false 
for  any  predicate  P,  we  have 

10  and  ~B  {  abort  }  false 

but  since  false  =>  10',  we  have  (2).  From  now  on,  we  will  neglect  the 
case  for  abort. 

For  (1) ,  assume  that  10  and  B  holds.  By  the  definition  of  pro¬ 
perty  modification,  we  have 

c  if  e=el 

e.course[el ;c]  = 

e. course  otherwise 

Similarly,  for  properties  semester  and  section#.  So 

(A)  el .course [el :c]  =  c  =  class. course  and 

el . semester [el : sem]  =  sem  =  class . semester  and 
el . section# [el : s#]  =  s#  =  class. section# 

and  by  10,  when  e~=el ,  we  have 

(B)  e. course  =  f(e). course  and 

e. semester  =  f (e) . semester  and 
e. section#  =  f  (e) . section# 

Let's  extend  the  skolem  function  f  by  adding  el  to  its  domain  so  that 
f(el)  =  class.  From  (A),  we  have 

el .course [el ;c  =  f( el). course  and 

el . semester [el : sem]  =  f (el ). semester  and 

el . section# [el ; s#’  =  f (el ). section# 

Together  with  (B) ,  we  have 

e. course [el :c]  =  f(e). course  and 
e. semester [el : sem]  =  f (e) . semester  and 
e. section# [el : s#]  =  f (e) . section# 

and  10  and  B  =>  10'  is  proved  and  we  have  10 { Til  10  QED 

Proof  of  I1{t1}i1 

We  first  proceed  forward,  using  the  property  of  class-there?  to 

show 

true{l  ;2  1 Q 
Q  const  y: CLASS 

y. course  =  c  and  y. semester  =  sem  and  y. section#  =  s# 

Statement  3  is  a  call  to  enough-space?  whose  property  is 
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B ' { enough-spaced?lB  =  true  =>  B'' 


B'  const  y: CLASS 

y. semester  =  sem  and  y. course  =  c  and  y. section#  =  s# 
B''  const  ytCLASS 

y. semester  =  sem  and  y. course  =  c  and  y. section#  =  s# 
and  y.max#  >  y . num-of-students 

Using  the  transaction  call  and  if  rules,  we  have 

C>i3j4tQ' 


Q'  const  y: CLASS 

y. course  =  c  and  y. semester  =  sem  and  y. section#  =  s# 
and  y.max#  >  y. num-of-students 

Hence,  we  have 

true{ 1 ;2 ;3 ; 4 }  Q ' 

but  it  is  clear  that 

nil;2;3;4lll 


So, 

(A)  Il{l  ;2  ;3 ?4}  II  and  Q'  is  true 

We  now  proceed  backward  by  pushing  II  back  one  statement, 
Il'(lO}ll 

II'  cl: CLASS 

cl. max#  >=  cl. num-of-students [class:class.num-of-students+l’ 
Next,  push  II'  up  to  statement  4, 

II  '  '{5;6;7;8;9}ll ' 


II''  const  x:CLASS;  z,cl,w:  CLASS 

[x. course  =  c  and  x. semester  =  sem  and  x.sectionf  =  s# 
and  z. course  =  c  and  z. semester  =  sem  and  z. section#  =  s# 

=>  cl. max#  >=  cl.num-of-students[z:z.num-of-students+l] ] 
or 

[  w. course  ~=  c  and  w. semester  ~=  sem  and  w. section#  "=  s# 
and  cl. max  >=  cl . num-of-students [class : 

class. num-of-students+l" ] 

We  will  omit  the  or  clause  from  II ' '  from  now  on  since  from  (A) ,  we 
know  there  is  a  y  that  makes  this  clause  inapplicable. 

Assume  that  in  Q' ,  the  existential  quantifier  y  takes  on  the  con¬ 
stant  cO,  so  we  have 


cO. course  =  c  and  cO. semes ter  =  sem  and  cO. section#  =  s#  and 
cO.max  >  cO . num-of-students 

Since  course,  semester  and  section#  together  form  a  key  in  CLASS,  the 
variables  x,  cl  and  z  in  II''  have  to  take  on  the  same  constant, 
namely  cO.  Hence  we  have  from  II'' 

cO.max  >=  cO . num-of-students [cO :c0 . num-of-students+1] 

This  is  reduced  to 
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cO.max  >=  cO . num-of-students  +  1 
This  is  true  because  from  Q'  we  have 

cO.max  >  cO . num-of-students  QED 


Specialized  Enrollment  Level 

In  this  level,  we  have  the  following  constraints  besides  10  and 

II. 


12  y , z ; ENROLLMENT ;  ex:  EXCLUSION-COURSES 
f>(y,z,ex) 

where 

P(y,z,ex)  =  ~ (ex. a=y. course  and  ex . b=z . course  and 

y. student=z . student  and  is (y. student , UNDERGRAD-STUD) 
and  is (z. student, UNDERGRAD-STUD) 

(no  undergrad  can  take  exclusive  courses) 

13  us: UNDERGRAD-STUDENT;  e : ENROLLMENT ;  pc : PREREQ-COURSE ; 

c: COURSE;  f ( e ): ENROLLMENT 

pc.c=c  and  e.STUDENT=us  and  e.course=c 

=>  f (e) . student=us  and  f (e) .course=pc.prereq 
(all  undergrad  must  take  all  prerequisites) 

14  us: UNDERGRAD-STUDENT 
AT-MOST (ENROLLMENT. US , 6 ) 

(undergrads  can  take  at  most  6  courses) 

15  gs: GRAD-STUDENT;  c: COURSE;  e: ENROLLMENT 
e.student=gs  =>  e. course  >=  400 

(grad  students  can  only  take  senior  undergrad  course) 

16  us: UNDERGRAD-STUDENT;  gc : GRAD-COURSE ;  e: ENROLLMENT 

e.student=us  and  e.course=gc  =>  gc. course  <  1500  and 

us. year  >=  3 

(undergrad  can  only  take  a  grad  course  if  the  course 
is  below  1500  level  and  s/he  is  at  least  a  junior) 

AT-MOST  is  a  predicate  defined  recursively  as  follows: 

AT-MOST (ENROLLMENT,  S,  n)  = 

e: ENROLLMENT 

(e=nothing  and  n  >=  0)  or 
(e~=nothing  and  e.student=s  => 

n  >-  1  and  AT-MOST (drop (ENROLLMENT, e) , s , n-1 ) ) 

(The  definition  of  AT-MOST  is  taken  from  Florent in [74] ) . 

At  this  level,  we  have  four  transactions  T2 ,  T3 ,  T4  and  T5 
corresponding  to  respectively 


(UNDERGRAD-STUDENT,  COURSE) . .enrol 
(GRAD-STUDENT,  COURSE) .. enrol 
(UNDERGRAD-STUDENT,  GRAD-COURSE) . .enrol 
(GRAD-STUDENT,  UNDERGRAD-COURSE) ..enrol 


To  prove  that  the  integrity  constraints  are  maintained  by  these  tran¬ 
sactions,  the  following  proofs  have  to  be  performed. 
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I0{t2  }  10 
I0{  T3  }  10 
I0{t4} 10 
I6{t4} 16 
I0{t5} 10 
Proof  of  I0{t2} 
T2  is  a  tr 


I1(t2  }  11 

12  {  T2  }  12 

I1{t3}  11 

I5{t3}  15 

I1{t41  11 

12  {  T4 }  12 

11  {t5}  11 

I5(t5} 15 

0 

nsaction 

of  the  form 

I3{t2}i3  I4{t2}i4 

I3{t4}i3  I4{t4}i4 


1.  no-exclusive-cour se? ( ;B) 

2 .  if  B  then  nil  else  abort 

3.  TtiT 


It  is  immediate  that  I0{l;2}l0  and  since  we  have  already  proved 
I0{t1}i0,  it  implies  that  10{l ;2 ;T1 } 10 ,  hence  I0{t1}i0  by  the  state¬ 
ment  concatenation  rule.  This  is  an  example  where  the  IS-A  relation¬ 
ship  of  transactions  can  facilitate  the  proof  of  correctness. 

Given  two  transactions  Tl  and  T2 ,  such  that  T2  is-a  T1 .  Very 
often,  a  significant  part  of  Tl  is  contained  in  T2  without  being  modi¬ 
fied.  Because  of  this,  a  significant  part  of  the  proof  of  T2  can  be 
drawn  directly  from  Tl ,  and  hence  the  process  is  simplified.  For  a 
IS-A  hierarchy  of  transaction,  the  savings  of  having  to  repeat  sub¬ 
proofs  can  be  substantial. 

In  the  case  above,  some  additional  code  (namely  statements  1  and 
2)  is  added  to  Tl  to  form  T2 .  Savings  of  subproof  come  from  the 
latter  part  of  T2 .  Savings  can  also  be  obtained  if  T2  =  T1;S  for  some 
additional  code  S.  In  the  case  when  T2  specializes  Tl  by  adding  some 
code  in  the  middle,  e.g. 

Tl  =  T11;T12  and 
T2  =  Til  ;R;T12  , 

the  proof  methodology  involves  the  following  steps  to  take  advantage 
of  the  fact  that  T2  is-a  Tl .  If  i{t2}i  is  wanted,  then  we  have  to 
prove 

1.  i(t111i'  and  and 
2  .  iMrI  I’ 

But  since  step  1  is  the  proof  of  Tl  wrt  constraint  I,  this  step  can  be 
skipped  in  proving  T2 . 

Using  the  IS-A  relationship  again,  we  have  II ( T2 } II . 


12  4 
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Proof  of  12  {t2  }  12 

no-exclusive-course?  is  a  derived  transaction  whose  form  and  property 
are  as  follows: 


transaction  no-exclusive-course?  /B  with 

Sarams  B  :  BOOL  init  true 
ocals  enrol-tuple:  ENROLLMENT 
for  ex  in  EXCLUSION-COURSES  do 

enrol-tuple  <-  get-object  from  ENROLLMENT  with 

course=ex.a  and  student=s  and 
ex. b=c 

if  enrol-tuple~=  nothing  then  B  <-  false 

end 


end 


true{ no-exclusive-course?}B=true  =>  Q 


Q  y: ENROLLMENT;  ex : EXCLUS ION-COURSES 

(ex.a=c  and  ex. b=y. course  and  s=y. student  and 
is (s, UNDERGRAD-STUD)  and  is (y. student , UNDERGRAD-STUD) ) 

Using  the  transaction  call  and  if  rules,  we  have 

12  (l  ;2  }q  and  12 

Two  useful  properties  of  exclusion  courses  are  next  presented  as  part 
of  their  semantics.  They  will  be  of  use  later. 


51  ex: EXCLUS ION-COURSES;  c: COURSE 
~(ex.a  =  c  and  ex.b  =  c) 

(exclusion  is  a  irreflexive  relation) 

52  el : EXCLUSION-COURSES ;  const  e2 : EXCLUSION-COURSES 
(el.  a  =  e2.b  and  el.b  =  e2.a) 

(exclusion  is  a  symmetric  relation) 

Going  the  other  direction,  we  have 
12  '  {  Tl }  12 


12'  const  el:  ENROLLMENT;  v,z:  add (el , ENROLLMENT) ; 
ex: EXCLUS ION-COURSES  ' 

P ' (y , z,ex) 

where 

P'  =  P<cour se [ el : c] /cour se , student [ el : s] /student> 
Since  the  function  add  is  defined  as 

is  (x,add  (x,C) )  <=>  ~is(c,C)  and  is[c,Cl(x,C) 

12 '  is  equivalent  to  the  following 


const  el : ENROLLMENT;  y , z : ENROLLMENT ;  ex : EXCLUS ION-COURSES 
P ' (el ,el ,ex)  and 
P  '  (y , el , ex)  and 
P  '  (el , z , ex)  and 
P  '  (y , z,ex) 

Lets  call  these  four  clauses  of  P'  as  clauses  1,2,3  and  4. 

For  clause  4  (within  the  scope  of  existential  quantifier  el), 
since  el  is  not  in  ENROLLMENT  (by  the  definition  of  add),  so 


Design  and  Verification  of  IISs  Using  TAXIS 


12  5 


Chapter  8  Verification  of  IISs 


P' (y,z,ex)  =  P (y,z,ex) 

and  since  el  is  not  free  in  4,  we  can  move  this  clause  outside  the 
scope  of  el,  and  it  is  reduced  to  12. 

Clause  1  is  reduced  to 
1 '  ex : EXCLUS ION-COURSES 

~(ex.a  =  c  and  ex.b  =  c  and  s  =  s  and  is ( s ,UNDERGRAD-STUD) ) 

Again,  1'  has  no  free  el,  so  we  can  move  it  outside  of  (Eel).  By  the 
irreflexive  property  of  EXCLUSION-COURSES  (SI),  we  have  clause  1' 
true . 

By  the  symmetric  property  (S2)  of  EXCLUSION-COURSES,  we  have 
clauses  2  and  3  reduced  to  a  single  clause,  say  clause  2,  which  is 

const  el:  ENROLLMENT;  y,z  :  ENROLLMENT;  ex : EXCLUS ION-COURSES 
P '  (y,el ,ex) 

But  this  is  Q. 

Hence  we  have  12  and  Q  =>  12',  and  II2(t2}i2  is  proved  QED 
Proof  of  I4{ T2 } 14 

After  the  syntactic  transformation  of  prerequisite  too-many- 
courses?  the  body  of  T2  has  the  form: 

1.  not-too-many-cour ses? ( ;B) ; 

2 .  . if  B  then  nil. else  abort  ; 

3.  {same  as  above) 

• 

where  not-too-many-cour ses?  is  a  derived  transaction: 

transaction  not-too-many-cour ses?  with 

?arams  B:BOOL; 

ocals  i : INTEGER  init  0; 
for  e  in  ENROLLMENT  do 

if  e. student  =  s  then  i  <-  i  +  1 

end 

if  i  <=  5  then  B  <-  true  else  B  <-  false 

end 

not-too-many-cour se?  has  the  following  property: 

tr ue{ not-too-many-cour ses} B-true=>AT-MOST (ENROLLMENT, s , 5 ) 

Going  forward,  we  have 
14 { 1 ;2 } 14  and  Q 
Q  AT-most (ENROLLMENT, s, 5) 

Next,  14  is  pushed  backward  so  that 
14  '  {  T2  1  14 
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14’  const  etiENROLLMENT 

AT-MOST ( add (et, ENROLLMENT) ,us,6)  and 

et. student  =  s  and  et. course  =  c  and  et. section#  =  s# 

To  show  that 

T4{l;2}l4',  we  have  to  prove  that 
14  and  Q  =>  14 ' 

First,  since  et. student  =  s,  so  the  addition  of  et  into  ENROLL¬ 
MENT  affects  only  s,  hence 

AT-MOST ( add (et, ENROLLMENT) , us, 6)  is  equivalent  to 

1.  AT-MOST (ENROLLMENT, us, 6)  and 

2 .  AT-MOST ( add ( e  t , ENROLLMENT )  , s , 6 ) 

Since 

AT-MOST (ENROLLMENT, s, 5)  =>  AT-MOST ( add (et , ENROLLMENT) , s , 6 ) ,  2  is 
true.  1  follows  directly  from  14,  hence  14  and  Q  =>  14'  and  I4{t2}i4 
is  proved  QED 

Using  the  IS-A  relationship  we  can  prove  that  I0{t3}i0  and 
II  {  T3  1 II . 

From  the  truth  of  the  prerequisite  senior-level-course?,  it  is 
trial  to  see  that  I5(t3}i5. 

Using  the  IS-A  relationship  between  T4  and  T1  again,  T4  preserves 
the  constraints  of  10,  II,  12,  13  and  14. 

From  the  truth  of  the  prerequisites  1500-level-course?  and 
senior?,  it  is  obvious  that  16  is  preserved  by  T4 . 

Using  the  IS-A  relationship,  10,  II  and  15  can  be  shown  to  be 
maintained  by  T5 . 

To  summarize  results  for  this  level,  we  have  four  transactions 
and  seven  constraints,  by  taking  advantage  of  the  fact  that  these 
transactions  are  organized  into  a  hierarchy  allows  us  to  draw  a  lot  of 
the  verification  results  which  otherwise  would  have  to  be  reworked, 
hence  the  verification  of  the  entire  IIS  can  be  proven  easier. 


^.4.  Yet  Another  More  Specialized  Level 

In  this  level,  in  addition  to  the  constraints  10  to  16,  we  have 
two  constraints: 

17  ptus:PT-UNDERGRAD-STUDENT 
AT-MOST (ENROLLMENT,  ptus,  3) 

18  ptgs:PT-GRAD-STUDENT 


Design  and  Verification  of  IISs  Dsing  TAXIS 


12  7 


Chapter  8  Verification  of  IISs 


AT-MOST{ ENROLLMENT,  ptgs,  2) 

There  are  also  two  more  transactions  (T6  and  T7)  corresponding  to 
(PT-UNDERGRAD-STUDENT, COURSE) . .enrol 
(PT-GRAD-STUDENT, COURSE) ..enrol 

The  following  properties  have  to  be  proven  for  this  level: 
lO{T6llO  I1{t6}i1  I2{t6}i2  I3{t6}i3  I4{t6}i4 

I7{  T6}  17 

I0{t7}i0  I1{t7}i1  I5{t7}i5  I7{t7}i7  I8{t7}i8 

The  proof  of  I7{t6}i7  and  I8{t7}i8  can  be  established  similar  to 
the  proof  of  I4{t1^I4.  The  rest  can  be  inferred  from  previous  levels 
and  by  the  IS-A  relationship  that  T6  IS-A  T2  IS-A  Tl  and  that  T7  IS-A 
T3  IS-A  Tl . 

We  have  demonstrated  that  the  concept  of  IS-A  hierarchy  as  a 
organizational  principle  of  IISs  allows  us  to  specify  and  verify  for¬ 
mal  properties  of  programs  in  a  layer-by-layer  fashion.  This  is 
because  the  IS-A  relationship  between  transactions  allows  us  to  con¬ 
centrate  on  the  'extra'  actions  (those  that  are  not  inherited  from 
generalizations)  performed  by  the  specialized  transaction.  The  veri¬ 
fied  properties  from  high  up  very  often  can  be  assumed  to  hold  (inher¬ 
ited)  .  More  and  more  formal  properties  can  be  inferred  as  we  move 
down  the  hierarchies  of  transactions.  This  'snow-balling'  effect  of 
accumulated  formal  properties  is  particularly  useful  for  situations 
where  there  are  a  lot  of  tedious  proofs  such  as  the  verification  of 
the  integrity  of  databases,  which  in  turn  is  the  most  important  pro¬ 
perty  of  an  interactive  information  system. 
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^.1.  Results  and  Contr ibut ions 

The  results  and  contributions  of  this  thesis  can  be  grouped  into 
six  categories  and  they  are  summarized  below: 

First,  the  language  TAXIS  is  developed.  The  version  presented 
here  is  a  revised  form  of  an  earlier  version  described  in  (Mylopoulos, 
Bernstein  and  Wong [78a, bl ) .  Among  the  major  changes  are:  metaclass 
definition  facilities  are  added,  which  allow  the  designer  of  an  IIS  to 
augment  the  built-in  properties  of  classes;  the  organization  of  data 
metaclasses  is  changed  to  facilitate  more  flexible  definitions  of  data 
classes.  The  complete  syntax  of  the  language  is  also  given,  for  the 
first  time,  in  the  thesis. 

Second,  a  denotational  semantics  for  TAXIS  is  developed.  Paral¬ 
lel  to  the  design  philosophy  of  TAXIS,  we  develop  a  model  which 
assigns  meaning  to  TAXIS  objects  in  a  uniform  way.  Each  TAXIS  class 
denotes  an  entity  which  has  an  associated  simple  set  which  includes 
one  entity  for  each  instance  of  the  class.  A  property  of  a  class 
denotes  a  function  whose  domain(s)  and  range  are  simple  sets.  All 
execution  units  are  given  meaning  in  terms  of  simple  actions  which 
either  insert  an  entity  in  a  set  or  delete  an  entity  from  a  set. 
Other  features  such  as  IS-A  hierarchies  and  inheritance  of  properties 
are  all  explained  in  terms  of  this  simple  framework. 

Third,  an  axiomatic  definition  of  TAXIS  is  given.  Among  the  new 
rules  are  the  rules  for  insert-object,  remove-object,  get-object  and 
for  loops. 

Fourth,  the  consistency  of  the  axiomatic  and  denotational  defini¬ 
tions  is  established.  First,  each  non-logical  symbol  in  the  assertion 
language  is  assigned  a  "meaning"  in  the  denotational  semantic  model  so 
that  each  assertion  can  be  assigned  a  value,  true  or  false.  Next,  the 
validity  of  each  axiom  is  proved  and  lastly,  for  each  rule  of 
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inference,  we  show  that  the  conclusion  of  the  rule  is  true  if  we 
assume  all  of  the  premises. 

Fifth,  a  design  methodology  for  IISs  is  developed.  The  methodol¬ 
ogy  proposed  here  emphasizes  the  IS-A  relationship  as  an  abstraction 
tool  that  encourages  classification  of  the  concepts  being  modelled 
rather  than  decomposition  of  a  problem  into  subproblems.  Thus, 
designing  an  IIS  is  treated  as  stepwise  refinement  but  along  a  dif¬ 
ferent  dimension  from  that  proposed  by  structured  programming  design 
methodology.  An  important  feature  of  our  approach  is  that  at  the  end 
of  each  refinement  step,  a  self-contained,  usable  system  is  obtained. 
We  have  presented  a  detailed  example  of  an  IIS  design  to  illustrate 
our  methodology. 

Lastly,  a  method  of  verification  of  IIS  correctness  is  proposed. 
Parallel  to  the  design  of  an  IIS,  the  correctness  of  an  IIS  is  esta¬ 
blished  in  a  stepwise  manner.  The  important  result  is  that  each 
refinement  of  the  design  can  be  specified  and  proven  correct  by  using 
the  results  of  the  previous  refinement. 


£.^.  Future  Work 

We  will  conclude  the  thesis  by  listing  some  of  the  interesting 
research  topics  which  we  think  deserve  closer  examinations.  Some  of 
these  topics  are  already  being  actively  looked  into. 

Incorporation  of  special  token  unknown  In  Mylopoulos  and 
Wong [80],  the  semantics  of  unknown  in  the  context  of  a  language  such 
as  TAXIS  is  examined.  Among  the  interesting  modification  in  the  for¬ 
mal  treatment  for  unknown  (along  with  nothing  )  is  that  we  are  forced 
to  use  (simple)  lattices  rather  than  sets  as  "meanings"  for  classes 
and  metaclasses,  along  the  lines  of  Scott’s  mathematical  semantics 
theory  (Tennent [ 75' ,  Donahue [75' ) . 

Design  of  Input/Output  Facilities :  TAXIS  does  not  offer  at  this 
time  input/output  facilities.  To  extend  it  in  order  to  have  it  pro¬ 
vide  such  facilities,  a  dialogue  facility  using  the  same  framework 
(classes  et  al.)  for  the  definition  of  pragmatic  aspects  of  a  user 
interface  has  been  designed  (Bar ron [80] ) . 

Implementation ;  A  TAXIS  parser  and  code  generator,  and  possibly 
an  interactive  system  through  which  a  designer  can  use  TAXIS  is  an 
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important  step  towards  testing  the  language.  Also,  there  are  impor¬ 
tant  theoretical  problems  such  as  the  mapping  of  the  IS-A  hierarchies 
of  relation  and  transaction  classes  into  relations  and  procedures  in  a 
real  DB  environment. 

Applications ;  Apart  from  the  design  of  individual  IISs  in  TAXIS, 
we  wish  to  explore  the  possibility  of  extending  TAXIS  to  make  it  suit¬ 
able  for  the  design  of  IISs  from  one  particular  applications  area, 
say,  accounting  or  inventory  control. 

Requirements  Specification:  The  idea  of  stepwise  specialization 
of  design  can  be  applied  to  other  areas  of  computer  science.  A  very 
promising  area  is  requirements  specification  of  software.  A  high 
level  specification  language  with  the  IS-A  concept  incorporated  can  be 
used  to  model  requirement  of  large  scale  software,  again,  in  a 
wise  manner  (Gr eenspan [ 81 ‘ ) .  The  constructs  of  the  language 
with  the  IS-A  concept,  will  require  a  formal  treatment  in  the 
of  what  this  thesis  provides. 


step- 

along 

spirit 
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Syntax  of  TAXIS 


Letter  =  A 

1  B 

1  C 

1  D  1 

E 

1  F 

1  G  1  H  1 

I 

1  J 

1  K  1 

L  1  M  1  N 

1  0 

1  P 

1  Q 

1  R  1 

S 

1  T 

1  U  1  V  1 

w 

1  X 

1  Y  1 

Z 

1  a 

1  b 

1  c 

1  d  1 

e 

1  f 

1  g  1  h  1 

i 

1  j 

1  ^  1 

1  1  m  1  n 

1  o 

1  P 

1  q 

1  r  1 

s 

1  t 

1  u  1  V  1 

w 

1  ^ 

1  y  1 

z 

Digit  =  0 

1 

2 

3  1 

4 

1  5  1 

00 

9  1 

Special- symbol 

=  < 

1  -  1 

{ 

1  = 

1  :=  1  -= 

1 

>  1 

<=  1  > 

=  1  (  1 

1  1  1 

1  1 

+  1 

'  1  1 

1  [| 

MM  ■  1 

f 

1  • 

1  / 

1  *  I 

1  *  1 

•  1  $ 

1  )  1 

#  1 

*  1 

1  1  . 

• 

1  /  1 

nothing  | 

1 

1  is 

SUCC  1 

pred 

1 

It  1 

gt  1  le  1 

ge 

1  attr 

1  pa rams 

prereq  | 

action 

1  result 

1 

key 

1  exc 

I  local  I  exc-property  |  exc-handler  |  is-a 
I  total  I  metaclass  |  with 

I  relation  |  aggregate  |  nil  |  for  |  mod  |  |  ] 

I  true  I  false  |  <- 

I  if  I  then  |  begin  |  else  |  while  |  do  |  in 
I  where  |  get-object  |  insert-object  |  and  |  on 
I  retrieve  |  delete  |  replace  |  into  |  from 
I  transaction  |  r-attr  |  end  |  remove-object 
Identifier  =  Letter  (  Character  ^ 

Character  =  Letter  |  Digit  |  Break-symbol 
Break-symbol  =-|?|#|*| 

Number  =  Integer  |  Real 
Integer  =  [  1  {  Digit  ^ 

Real  =  Integer  .  Digit  {  Digit  ^  [  E  [  +  |  -  ]  Digit 

[  Digit  ]  ] 

Token  =  Atomic-token  |  Aggregate-token 
Atomic-token  =  Number  |  Atom 
Atom  =  '  {  Character  |  ' 

Aggregate-token  =  [  Attribute-value-list  ] 

Attribute-value  =  Identifier-list  :  Token 
Permanent-assignment  = 

Identifier  :=  (  Simple-class-definition  |  Token  ) 
Simple-class-definition  =  Simple-class  [  is-a  Class-list  ] 
Simple-class  =  Finitely-defined 

I  Form-defined 
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I  Aggregate-class 

Finitely-defined  =  {|  Token-list  |  Interval-list  |} 

Interval  =  Token  : :  Token 

Form-defined  =  Class  |  Class  @  Form-defined 
Aggregate-class  =  [|  Attribute-property-list  [] 
Attribute-property  =  Identifier-list  :  Class 
Property-definition  =  Property-category  Identifier  on 

Class-list  is  Class 

Property-category  =  attr  |  r-attr  |  params  [  prereq 

I  key  I  exc  |  local  |  exc-property 
I  result  I  exc-handler  |  action 

Class  =  Class-name  |  Simple-class 
Class-name  =  Identifier 

I  (  Class-name-list  )  (  ..  |  .  )  Identifier 
I  Class-name  (  . .  |  .  )  Identifier 
Metaclass-definition  = 

metaclass  Identifier  [  is-a  Identifier-list  ] 

with  [  Attribute-category  ]  [  R-attr ibute-category  ]  end 

Attribute-category  =  attrs  Attribute-list 
Attribute  =  Identifier-list  :  Class 

[  total  ] 

R-attr ibute-category  =  r-attrs  Attribute-list 
Data-class-def ini tion  = 

Identifier  Identifier  [  is-a  Class-list  1 

with  [  Key-category  ]  [  Attribute-category  ] 

[  R-attr ibute-category  ]  end 
Key-category  =  keys  Key-property-list 
Key-property  =  Identifier  :  (  Identifier-list  ) 

Expression  =  nil 

I  Identifier 
I  [  Expression 
I  Token 

I  Expression  Binary-operator 
Expression 

I  Unary-operator  Expression 
I  Attribute-function-expression 
Binary-operator  =  Property-selection-operator 

I  Arithmetic-operator 
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I  String-operator 
I  Relational-operator 
I  Logical-operator 

Property-selection-operator  =  . .  |  , 
Arithmetic-operator  =  <  |  -  |  *  |  **  |  mod 

String-operator  =  | | 

Relational-operator  =  <  |  >  |  <=  |  >=  |  is 


1  is-a  1  It  1  gt  1 

le  1 

ge 

Log ical-operator 

=  or  1  and 

Unary-operator  = 

-  1  pred  1  succ 

Attribute-function-expression  = 

Identifier  (  Simple-expression-class-list  ) 

[  Exception-handler-list  ] 
Statement  =  Property-modification 
I  Transaction-call 
I  Conditional 
I  Block 
I  While 
I  For 

I  Operator-statement 
Property-modification-operator  =  <- 

Transaction-call  =  Class  (Expression-list ; Identifier-list) 

[  Exception-handler-list  ] 

Exception-handler  =  exc-handler  for  Class-name  is  Class-name 
Conditional= 

if  Expression  then  Statement 

[  else  Statement  ] 

Block-statement  =  begin  [  Local-variable-category  ] 

Block-body 

end 

Local-variable-category  =  local  Variable-list 
Variable  =  Identifier  :  Class-name 
Block-body  =  Statement-property-list 

Statement-property  =  [  (  Identifier  |  Empty  )  1  [  :  ] 

[  Statement-class  ]  ; 

while-statement  =  while  Expression  do 

Statement-list 
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end 

For-statement  =  for  Identifier  in  Class  do 

Statement-list 

end 

Operator-statement  =  Get-object-statement 

I  Idd-statement 

I  High-level-relational-statement 
Get-object-statement  = 

get-object  from  Class-name 

with  (  Expression  ) 

Idd-statement  =  Insert-statement 

I  Remove-statement 

Insert-statement  =  insert-object  Identifier  in  Class-name 

with  Expression 

Remove-statement  =  remove-object  Identifier 
High-level-relational-operator  = 

Quel-operator  for  Tuple-variable-list 

(  Retrieve-body  |  Delete-body  |  Replace-body  ) 
[  Where-clause  1 

Quel-operator  =  retrieve  |  delete  |  replace 
Tuple-variable  =  Identifier  in  Class-name 
Retrieve-body  =  into  Class-name  (  Expression-list  ) 
Delete-body  =  from  Identifier 
Replace-body  =  Identifier  (  Assignment-list  ) 

Assignment  =  Identifier  <-  Expression 
Where-clause  =  where  (  Expression  ) 

Transaction-definition  = 

transaction  Identifier  [  is-a  Class-hame-list  ] 
with 

[  params  [  (  Identifier-list  )  ] 

[  Local-variable-category  ] 

[  prereqs  Condit ion^proper ty-list  1 
[  actions  Statement-property-list  ] 

[  results  Condition-property-list  ] 


end 

Condition-property  =  Expression-property  [  exc  Class-name 

(  Expression-list  )  1 

Program  =  Statement-list  . 
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Statement  =  Class-definition  |  Property-definition 
I  Permanent-assignment 
Class-definition  =  Metaclass-definition 

I  Simple-class-definition 
I  Data-class-def inition 
I  Transaction-definition 
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Glossary  of  Terms  in  Chapter  3 

aggregate  class  3.4.3 

aggregate  token  3.3 

atom  3 .3 

atomic  token  3.3 

attribute  3 . 5 

attribute  category  3.6 

attribute  function  expression  3.8.3 

attribute  property  3.4.3 

attribute  value  3.3 

binary  operator  3.8.1 

block  3.9.4 

character  3 .2 

class  name  3 . 5 

class  3.5 

condition  statement  3.9.3 
data  class  definition  3.7 
delete  body  3. 9. 7. 3 

digit  3.1 

exception  handler  3.9.2 

expression  class  3.8 

expression  property  3.8.2  .2 
finitely  defined  3.4.1 

for  statement  3.9.6 
form  defined  3.4.2 

high  level  relational  operator  3. 9. 7. 3 

idd  statement  3. ,9. 7. 2 

identifier  3  .2 

insert  3 . 9 . 7 . 2 

integer  3.2 

interval  3.4.2 

key  category  3  .  7 

key  property  3 . 7 

letter  3 .1 

local  variable  category  3.10 


Design  and  Verification  of  IISs  Using  TAXIS 


140 


logical  operator  3. 8. 1.5 
metaclass  definition  3.6 
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number  3.2 

operator  statement  3.9.7 

permanent  assignment  3.3 

program  3.11 
property  definition  3.5 

property  modification  operator 
property  type  3.5 

Quel  operator  3. 9. 7. 3 

r-attribute  category  3.6 

real  3 .2 

relational  operator  3. 9. 7. 3 
remove  3 . 9 . 7 .3 
replace  body  3. 9. 7. 3 

retrieve  body  3. 9. 7. 3 

simple  class  3.4 
simple  class  definition  3.4 

statement  3.9 

string  operator  3. 8. 1.3 

token  3.3 

transaction  call  3.9.2 

transaction  class  definition 
tuple  variable  3. 9. 7. 3 

unary  operator  3.8.2 

variable  3. 9. 7. 3 

where  clause  3. 9. 7. 3 

while  3.9.5 


3.9.1 


3.10 
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Glossary  of  terms  in  Chapter  5 


c 

set  of  abstract  entities  for  classes 

and  metaclasses  (3.1) 

cc 

set  of  class  entities  (3.1) 

CM 

set  of  metaclass  entities  (3.1) 

C* 

set  of  syntactic  class  definition  (3.2) 

C*T 

set  of  transaction  class  entities  (5.3) 

C*E 

set  of  expression  class  entities  (4.5) 

C*  (P) 

set  of  class  definition  for  program  P 

(7) 

D 

domain  of  discourse  (3.1) 

delete (a) ( s) 

returns  a  state  after  the  deletion  of 

entity  a  in  state  s  (5.1) 

Ep 

the  set  of  entities  in  program  P  (2) 

f  (P)  (c) 

assigns  name  c  to  a  class  definition  in 

program  P  (7) 

F(T) 

semantic  function  for  transaction  classes 

(5.3) 

G(E) 

semantic  function  for  statement  classes 

(5.2) 

H(E) 

semantic  function  for  expression  classes 

(4.5) 

insert (c) s 

returns  a  state  after  the  insertion  of  a 

new  entity  into  C 

(5.1) 

is(t,C) 

returns  1  if  token  t  is  an  element  of  the 

extension  of  class  C  (4.2) 

lin ( t, s) 

linearizes  state  transition  t  in  state  s 

(6.2) 

M* 

set  of  syntactic  metaclass  definitions  (3.2) 

M(el  ,e2  ) 

isomorphism  from  C*  to  CC  and  M*  to  CM  (2) 

PE 

set  of  property  entities  (3.1) 

p-value (  c  , i ) 

returns  the  p-value  of  the  i  attribute 

of  c  (3  .2  ) 
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P-exp  ( el  ,  e2  ) 

IS-A  constraint  predicate  for  expressions 

(6) 

PE(P) 

the  set  of  property  entities  for  program 

P  (7) 

P-ext (dl , d2 ) 

IS-A  constraint  predicate  for  class  and 

metaclass  (4.1) 

P-s(Sl  ,S2  ) 

IS-A  constraint  predicate  for  statements 

(6.2) 

R 

infinite  set  of  tuple  entities  (3.2) 

R-equ ( si  ,  s2  ) 

states  si  and  s2  are  r-equ  if  they  are 
undistinguishable  up  to  permutation  of 

elements  in  R  (4.1) 

Sp 

set  of  states  in  program  P  (4) 

side-effects ( t) 

returns  the  net  side-effects  of  state 

transition  t  (6.2) 

SM- init (P) 

syntactic  mapping  for  init  clause  (7.1) 

SM-inser t (P) 

syntactic  mapping  for  insert  statement  (7.1) 

SM-blk (P)  . 

syntactic  mapping  for  blocks  (7.1) 

SM-inh (P) 

syntactic  mapping  for  property  inheritance 

(7.1) 

SM-retr (P) 

syntactic  mapping  for  retrieve  operator 

(7.4) 

SM-del (P) 

syntactic  mapping  for  delete  operator 

(7.4) 

SM-rep(P) 

syntactic  mapping  for  replace  operator 

(7.4) 

Tp 

set  of  state  transformations  in  program 

P  (2) 

update ( a , i , b) s 

returns  the  state  after  the  i  attribute 

of  a  is  assigned  b  (5.1) 

V  ( t)  s 

returns  the  value  of  variable  t  in  state  s 

(4.1) 

vp(t,p) 

the  property  value  p  of  tuple  t  (4.1) 

<  < 

the  denotation  of  IS-A  (2) 

i  c 

denotation  for  class  ANY  (3.2) 

oc 

denotation  for  class  NONE  (3.2) 

IM 

denotation  for  metaclass  META-ANY  (3.2) 

OM 

denotation  for  metaclass  META-NONE  (3.2) 
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[c  (x)  ] 

[~x] 

[a, i,b] 


side-effects  of  inserting  x  into  class  c 

(6.2) 

side-effects  of  deleting  x  (6.2) 
side-effects  of  updating  the  i  attribute 
of  tuple  a  to  b  (6.2) 


Design  and  Verification  of  IISs  Using  TAXIS 


144 


Appendix  D 

Proofs  of  Selected  Theorems 

We  will  prove  theorems  5. 6. 2.1,  5. 6. 2. 2  and  5. 6. 3.1  in  this 

appendix. 

Theorem  If  ts  =  s'  where  s  =  (v,  vp,  mem)  and  s'  =  (v',  vp' , 

mem' ) ,  then 

(1)  [c(x)]  mb-of  side-ef fects ( t)  iff  x  mem  c'  =>  c'  =  1C  and  x  mem' 

c . 

(2)  [“Xj  mb-of  side-ef fects ( t)  iff  x  mem  c'  ~=>  c'  =  1C  and  x  mem' 
c'  =>  c'  =  1C 

(3)  if  v(a,i)  ~=  b  then  [a,i,b]  mb-of  side-ef fects ( t)  iff  v'(a,i)  = 

b 

The  proof  will  be  carried  out  in  terms  of  an  induction  on  the 
number  of  compositions  n  used  to  build  t. 

Proof  of  (1 ) . 

Induction  base:  If  n  =  0  then  t  =Ident(S)  and  the  assertion  is 
trivially  true. 

Induction  step:  It  is  assumed  that  (1)  holds  for  n  <=  m  and  it 
must  be  shown  for  n  =  m+1 .  Let  t  =  t0@ ' ' ,  where  tO  is  a  primitive 
transformation,  and  f's  =  s'',  and  s''=  (v'',  vp'',  mem'').  We  will 
distinguish  three  cases  depending  on  whether  tO  is  an  insertion,  dele¬ 
tion  and  update: 

(i)  If  to  is  an  insertion  there  are  two  cases: 

to  =  [c(x)l:  then  it  must  be  that  [c(x)I  ~mb-of  side- 

ef  fects  {  t  '')  ,  otherwise,  by  induction  hypothesis,  x  mb-of  s' '(c) 
and  to  would  not  be  applicable  to  s'';  it  follows  easily  from 
this  observation  that 

[c(x)]  mb-of  side-ef fects ( t)  <=>  (def.  side-effects) 

X  mem' '  c'  =>  c'  =  1C  and  x  mem'  c  <=> 

X  mem  c'  =>  c'  =  1C  and  x  mem'  c 
to  =  [c '  (y)  ]  : 

[c(x)]  mb-of  side-ef fects ( t)  <=>  [c(x)]  mb-of  side-ef fects ( t '' ) 
<=>  X  mem  c'  =>  c'  =  1C  and  x  mem''  c  <=>  x  memc '  =>  c'  =  1C  and 
x  mem'  c. 

(ii)  If  to  is  a  deletion  then  either  side  of  (1)  implies  that  tO  ~= 
[-x] .  It  follows  easily  from  this  observation  that 
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[c(x)]  mb-of  side-effects (t)  <=>  [c(x)]  mb-of  side-ef fects ( t ' ’ )  <=>  x 
mem  c'  =>  c'  =  1C  and  x  mem''  c  <=>  x  mem  c'  =>  c'  =  1C  and  x  mem'  c. 

(iii)  If  to  is  an  update  it  cannot  affect  the  membership  of  an  entity 
in  the  extension  of  a  class  entity,  so  (1)  holds  again. 

Proof  of  (2  )  . 

Induction  base:  as  with  (1) 

Induction  step:  as  with  (1),  we  will  consider  three  cases: 

(i) ,  (iii)  If  to  is  an  insertion  or  an  update  then  it  cannot 

affect  a  previous  deletion,  so  (2)  holds.  Note  that  in 

order  for  this  to  be  true,  it  must  be  that  within  a 
transformation,  a  name  used  in  a  deletion  cannot  be  used 

later  in  an  insertion.  This  constraint  was  imposed  on 

transformation  in  T  in  section  5.4.1. 

(ii)  If  to  is  a  deletion,  we  will  distinguish  two  cases 

to  =  [-x] :  If  [-x]  mb-of  side-ef fects ( t)  then  it  must  be 
that  it  was  added  because  of  tO ,  otherwise  tO  would  not  be 
applicable  to  s''.  Moreover,  it  must  be  that  [c(x)]  ~mb-of 
side-ef fects ( t)  because  if  it  was,  [-xl  would  not  have  been 
added  to  side-ef fects (t) .  It  follows  that  x  mem  c'  ~=>  c'  = 


1C  and  that  x  mem'  c 
c 


I  _ 


=> 


c '  => 


'  =  1C  and  X  mem'  c'  => 


c 

c 


I  _ 


=  1C.  Conversely,  suppose  x  mem 


I  _ 


=  1C.  Since  x  mem  c' 


=> 


c'  =  1C,  it  must  be  that  [c(x)]  ~mb-of  side-ef fects ( t '' )  and 


therefore  [-x*  mb-of  side-ef fects (t) . 

to  =  [-y] :  to  cannot  interfere  with  [-xJ  now  so  (2) 
trivially. 


holds 


Proof  of  (3  )  . 

Induction  base:  as  with  (1)  and  (2) 

Induction  step:  Suppose  that  the  assertion  holds  for  n  =  m  and  we 


will  show  it  for  n  =  m+1 .  Let  t  =  t0@ '  '  and  f's 


I  I 


Assume  first 


that  [a,i,b]  mb-of  side-ef fects ( t) .  This  means  that  either  during  an 
insertion  or  during  an  update,  [a,i,b'  was  added  to  side-ef fects ( t) . 
Let  tl  be  the  primitive  transformation  that  caused  [a,i,b]  to  be  added 
and  assume  that  t  =  t2@tl@t3.  By  the  induction  hypothesis,  it  must  be 
that  if  s'''  =  tl@t3s,  v(a,i)  ~=  b  and  v'''(a,i)  =  b.  Now  t2  can 
change  this  either  with  a  deletion  or  an  update,  but  in  either  case, 
[a,i,b]  will  be  removed  from  side-ef feet ( t) ,  according  to  the 
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definition  of  side-effects. 

To  prove  the  converse,  assume  that  v(a,i)  ~=  b  and  v'(a,i)  =  b. 

Then  it  is  either  the  case  that  v''(a,i)  =  b  or  =  ~b.  In  the  first 
case,  it  must  be  that  [a,i,b]  mb-of  side-ef fects ( t ' )  and  it  must  be 
that  to  does  not  affect  this,  otherwise  [a,i,b]  would  not  be  an  ele¬ 
ment  of  side-ef fects ( t) .  In  the  second  case,  it  must  be  that  tO 
causes  the  addition  of  [a,i,b]  in  side-ef fects ( t) ,  otherwise  v(a,i) 
would  not  be  equal  to  b. 

Theorem  side-ef  fects  (t)  =  side-ef  fects  (u)  iff  t  =w  u 

Proof:  Suppose  that  t  =w  u  but  side-ef fects ( t)  "=  side- 

effects(u).  Let  r  be  one  of  the  side-effects  in  side-ef fects ( t)  or 
side-ef fects (u)  but  not  in  both  (assume,  without  any  loss  of  general¬ 
ity,  that  r  is  in  side-ef fects ( t) ) .  If  r  =  [c(x)]  then  by  Theorem 
5. 6. 2.1,  it  must  be  that  tk  ~=  sk  for  some  k  where  t,  u  are  applica¬ 
ble,  contradicting  the  hypothesis.  If  r  =  [-xl  or  r  =  [a,i,b]  similar 
comments  apply.  Thus  it  must  be  that  side-ef fects ( t)  =  side- 

ef  fects  (u)  . 

Conversely,  suppose  that  side-ef fects { t)  =  side-ef fects (u) .  If 
there  exists  a  state  k  such  that  tk  ~=  uk,  let  tk  =  k'  and  uk  =  k''. 

The  difference  between  k',  k''  can  be  translated,  according  to  the 

definition  of  a  state  to  a  difference  in  the  class  extension  or  pro¬ 
perty  extension  functions  associated  with  k'  and  k''.  In  either  case, 
theorem  5. 6. 2.1  guarantees  that  these  differences  translate  to 
corresponding  differences  of  side-ef fects ( t) ,  side-ef fects (u) ,  thus 
contradicting  the  hypothesis. 

Theorem  5. 6. 2. 2  no  longer  holds  if  weak  equivalence  of  t,  u  is 
replaced  with  strong  equivalence.  For  example 
t  =  update (a , i , b) 

u  =  update (a , i , b)  @  update ( a , i , c) 

have  side-ef fects ( t)  =  side-ef fects (u)  but  t  is  not  applicable  to  a 
state  where  the  p-value  of  a  for  the  property  with  attribute  i  is  b, 
while  u  is  applicable. 

Theorem  5.6.^.! 

If  T1  and  T2  are  transaction  classes  such  that  Den(Tl),  Den(T2) 
satisfy  the  structural  IS-A  constraint  and  the  transaction  constraint. 
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and  El,  . . . ,  En  are  arbitrary  expressions,  then 

P-s  (Den (T1 (El ,  En) ) ,  Den(T2(El,  En) ) ) 

where  P-s  is  the  IS-A  predicate  for  statements. 

Proof : 

Let  Tl  be  a  transaction  with  prerequisite,  action  and  result 
statements  SI,  ...,  Sm,  to  be  evaluated  in  that  order.  Let  T2  be  a 
specialization  of  Tl  and  S  be  a  statement  in  the  body  of  T2 .  We  have 
to  prove: 

P-s  (Den  (Tl  (El ,  ...,  En)  )  ,  Den(T2(El,  ...,  En)  )  ) 

Proof 

If  Den(S)  <<  Den(Si),  then  by  the  transaction  constraint,  G(S)  is 
an  independent  specialization  of  G(Si)  wrt  G (S ( i-1 ) @ . . . @G ( SI ) .  We 
would  like  to  show  that  for  all  state  s  for  which  the  statements 
T1(E1,  ...,  En)  and  T2(El,  ...,  En)  are  defined: 
side-effects (lin (Den (T2  (El ,  ...,  En)),s))  C 

side-effects ( lin (Den (Tl (El ,  ...,  En)),s))  Assume 

that  se  is  a  side-effect  in  T2  but  not  in  Tl .  There  are  three  cases 
to  consider: 

(a)  se  =  [c  (x)  ] 

The  insertion  can  occur  in  two  places:  during  the  execution  of 
Si@S  (  i-1 ) @ . . . @S1  or  during  Sn@ . . . @S ( i+1 ) .  In  the  former  case,  it  must 
be  during  the  execution  of  S  of  T2  that  causes  the  deletion  of  entity 
X,  but  this  would  violate  the  transaction  constraint  which  states  that 

side-effects (lin(G(Si@. . .@S1) ,s) )  C 

side-effects ( lin (G (S@S ( i-1 ) @ . . . @S1 ) , s) ) 

Hence  x  can  not  be  deleted  in  S. 

In  the  latter  case,  it  must  be  that  the  execution  of  S  that 
prevented  the  side-effects  [c(x)]  in  the  execution  of  Sn@ . . . @S ( i+1 ) . 
S  can  only  do  this  by  inserting  x  to  some  other  class.  But  in  this 
case  Sn@ . . . @S ( i+1 )  would  be  undefined  since  x  is  already  been  used  and 
this  violates  our  assumption  that  Tl  and  T2  are  defined  in  state  s. 

(b)  se  =  [-x3 

If  [-x]  mb-of  side-ef f ects ( lin (G (S i@ . .  . @S1 )  , s) ) ,  by  transaction 
constraint,  [-x]  mb-of  side-ef f ects ( 1 in (G (S@S ( i-1 ) @ ... @S1 ), s) ) .  If 
[-X]  mb-of  side-effects(lin(G(Sn@. . .@S(i+l) ) ,s) )  ,  then  it  must  be  dur¬ 
ing  the  execution  of  S  that  causes  [-x]  to  be  excluded  from  the  side- 
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effects  of  T2 ( . . . ) •  This  again  would  make  Sn@ . . . @S ( i+1 )  undefined 
since  it  tries  to  delete  an  entity  that  has  already  been  deleted. 

(c)  se  =  [a,i,bi 

Similar  argument  can  be  given  to  show  that  se  has  to  belong  to 
the  side-effects  of  T1(E1,  ...»  En)  as  well. 

In  the  case  that  statement  S  is  an  independent  continuation  of 
some  statement  of  T2 ,  similar  argument  can  be  made  to  show  the  theorem 
to  hold. 
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David  B.  Wortman,  December  1972 
[Ph.D.  Thesis.  Computer  Science  Department, 

Stanford  University,  1972] 

AN  APL  TERMINAL  APPROACH  TO  COMPUTER  M/vPPEv^G 
R.  Kvaternik,  December  1972 
[M.Sc.  Thesis,  DCS.  1972] 

AN  IMPLEMENTATION  LANGUAGE  FOR  MINICOMPUTERS 
G.G.  Kalmar,  January  1973 
[M.Sc.  Thesis,  DCS,  1972] 

COMPILER  STRUCTURE 

W.M.  McKceman,  January  1973 

[Proceedings  of  the  USA-Japan  Computer  Conference,  1972] 
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*  CSRC-24  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 

ENGINEEWNG 

J.D.  Gannon  (ed.),  March  1973 

CSRG-25  THE  INVESTIGATION  OF  SERVICE  TIME  DISTRIBUTIONS 
Eleanor  A.  Lester.  April  1973 
[M.Sc.  Thesis,  DCS,  1973] 

CSRG-26  PSYCHOLOGICi\L  COMPLEXITY  OF  COMPUTER  PROGR^VMS: 
AN  INITIAL  EXPERIMENT 
Larry  Weissman,  August  1973 

*  CSRG-27  STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  IVortman,  October  1973 

*  CSRG-28  ON  REDUCED  MATRIX  REPRESENTATION  OF  LR(k) 

PARSER  TABLES 

Marc  Louis  Joliat,  October  1973 

[Ph.D.  Thesis.  EE  1973] 

CSRG-29  A  STUDENT  PROJECT  FOR  AN  OPERATING  SYSTEMS  COURSE 
B.  Czarnik  and  D.  Tsichritzis  (eds.),  November  1973 


»  CSRG-30 


A  PSEUDO-MACHINE  I'UR  CODE  GENERATION 
Henry  John  Pasko,  Decemher  1973 
[M.sJ.  Thesis,  DCS  1973] 


CSRG- 


31  AN  ANNOTAED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM  ENGINEERING 
J.D.  Gannon  (sd.),  Second  Edition,  March  1974 


»  CSRG-32  SCHEDULING  MULTIPLE  RESOURCE  COMPUTER  SYSTEMS 
E.D.  Lazowska,  May  1974 
[M.Sc.  Thesis.  DCS.  1974] 


^  CSRG-33  AN  EDUCATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 
F.  Lochovsky  and  D.  Tsichritzis,  May  1974 
[INFOR,  14  (3).  pp.270-273,  1976] 

♦  CSRG-34  .ALLOCATING  STORAGE  IN  H1EIU\RCH1CAL  DATA  BASES 
P.  Bernstein  and  D.  Tsichritzis,  May  1974 
[Information  Sy.stem.s  Journal,  v.l,  pp.  1 33- 140] 


*  eSRG-af)  ON  IMPLEMENTATION  OF  RELA'I’IONS 
D.  Tsichritzis.  May  1974 

^  CSRG-3G  SIX  PL/I  COMPILERS 

D.B.  y/ertman,  P.J.  Khaiat,  and  D.M.  Lasker,  August  1974 
[Software  Practice  and  Evnorionre,  v.R,  n.3. 

July-Sept.  1976] 


A  METHODOLOGY  FOR  STUDYING 
OF  COMPUTFK  PUOGRAMS 


IE  PSYCIiOLOGICAL  COMPLEXITY 


l.nurcmcc  ,V1.  Wr't.'ctiyinr),  Augu.’it  197''! 
[Ph.D.  The.siH,  DCS.  1974] 


^  CSRG-37 


CSRG-38  AN  IN\'ESTTGATION  OF  A  NEW  METHOD  OF  CONSTRUCTING  SOFTWARE 
David  M.  Lasker.  September  1974 
[M.Sc.  Thesis,  DCS,  1974] 

CSRG-39  AN  ALGEBPiAIC  MODEL  FOR  STRING  PATTEiLNS 
Glenn  F.  Stewart,  September  1974 
[M.Sc.  Thesis.  DCS.  1974] 

CSRG-40  EDUCATIONAL  DATA  BASE  SYSTEM  USER’S  M.YNUAL 
J.  Klebanoff.  F.  Lochovsky.  A.  Rozitis,  and 

D.  Tsichritzis,  September  1974 

CSRG-41  NOTES  FROM  A  WORKSHOP  ON  THE  ATTAINMENT  OF 
RELIABLE  SOFTWARE 

David  B.  Wortman  (ed.).  September  1974 

CSRG-42  THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 
B.L.  Clark  and  F.J.B.  Ham.  September  1974 

CSRG-43  A  DATA  BASE  PROCESSOR 

E. A.  Ozkarfihan,  S.A.  Schuster  and  K.C.  Smith, 

November  1974  [Proceedings  National  Computer 
Conference  1975,  v.44,  pp. 379-308] 

CSRG-44  MATCHING  PROGRAM  AND  DATA  REPRESENTATION  TO  A 
COMP UTl NG  EN VI RON M E NT 
Eric  C.R.  Hehner,  Novemver  1974 
[Ph.D.  Thesis,  DCS.  1974] 

Sec  Computer,  Vol.9,  No. 9,  .\ugust  1976,  pp. 65-70. 

CSRG-45  THREE  APPROACHES  TO  RELIABLE  SOFTWARE:  LANGUAGE  DESIGN. 
DYADIC  SPECIFICATIONS.  COMPLEMENTARY  SEMANTICS 
J.E.  Donahue,  J.D.  Gannon,  J.V.  Guttag  and 
J.J.  Horning,  December  1974 


CSRG-46  THE  SYNTHESIS  OF  OPTIMAL  DECISION  TREES  FROM 
DECISION  TABLES 

Helmut  Schumacher,  December  1974 

[M.Sc.  Thesis,  DCS,  1974;  CACM,  v.l9,  n.6,  June  1976] 


CSRG-47  LAJ^GUAGE  DESIGN  TO  ENHANCE  PROGRAMMING  RELlABlLiiW 
John  D.  Gannon. January  1975 
[Ph.D.  Thesis,  DCS,  1975] 


C3RG-48  DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.M.  Turnbull,  Januar}'"  1975 
[Ph.D.  Thesis,  EE,  1974] 


CSRG-49  A  NETWORK  FRAMEWORK  FOR  RELATIONAL  IMPLEMENTATION 


D.  Tsichritzis,  February  1975  [in  Data  Rase  Description, 
Donguo  and  Nijsson  (cds.).  North  Iloltarul  1‘ublishing  Co.] 
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*  CSRG-50  A  UNIFIED  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 

AND  RELATIONS 

P.A.  Bernstein,  J.R.  Swenson  and  D.C.  Tsichritzis 
February  1975  [Proceedings  of  the  ACM  3IGM0D 
Conference,  1975] 

*  CSRG-51  ZETA:  A  PROTOTYPE  REI.ATIONAL  DATA  RASE  MANAGEMENT  SYSTEM 

M.  Hrodi(^  (od).  February  1975  [P  roeetniings  Pacific  ACM 
Conference,  1975] 

CSRG-52  AUTOMATIC  GENEP^ATION  OF  SYNTAX-REPAIRING  AND 
PAPAGRAPMING  PARSERS 
David  T.  Barnard.  Mai'ch  1975 
[M.Sc.  Thesis,  DCS,  1975] 

*  CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FUR  RELATIONAL 

DATA  BASES 

J.H.  Gillcs  Farley  and  Stewart  A.  Schuster,  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGIUVPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

J.V.  Guttag  (ed.).  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  Pl./l  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  May  1975 

C3RG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [Proceedings  Very  Liirge 
DataBase  Conference.  1975] 

C3RG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 
Eric  C.K.  Hehner,  July  1975 

sec  Acta  Inforniatica  Col.  10.  No. 3.  pp.2S9-2‘i3.  197B 

CSRG-5a  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Kans  Albrecht  Schmid  and  J.  Richard  Swenson, 

July  1975  [Proceedings  of  the  ACM  SIGMOD  Confere.nce,  1975] 


*  r 


J-59  THE  SPECIFICATION  AND  APPEiCATlUN  TO  PROGRAMMING 
OF  ABSTRACT  DATA  TfPES 
John  Y.  Guttag,  September  1975 
[Ph.D.  Thesis.  DCS.  1975] 


*  CSRG-GO  NORMALIZATION  AND  FUNCTIONAL  DEPE’NDENCIES  IN  THE 

RELATIONAL  DATA  BASE  MODEL 
Phillip  .Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS.  1975] 

*  CSRG-B1  LSL;  A  TJNK  AND  SET.ECTiON  LANGUAGE 

D.  TsicLirilzis,  November  1975  [Proceedings  ACM 
SICMOD  Cunfcrcncc,  I!)?!)! 
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*  CSRG-62 


CSRG-63 


CSRG-64 


CSRG-65 


CGRG-B6 


CSRG-67 


*  C3RG-68 


C3RG-69 


’  CSRG-70 


'  CSRG-71 


CSRG-72 


COMPLEMENTARY  DEFINITIONS  OF  PROCR/\MMING  LANGUAGE 
SEMANTICS 

James  E.  Donahue,  November  1975 
[Ph.D.  Thesis,  DCS,  1975] 

AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING  HEURISTICS 
Lazio  Sugar,  December  1975 
[M.Sc.  Thesis.  DCS.  1975] 

A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

S.A.  Schuster,  E.A.  Ozkarahan,  and  K.C.  Smith, 

February  1  976  [Proceedings  Nnt.innnl  Gnmputer 
Conference  1976,  v.45,  pp.B55-B6E] 

PERF'ORMANCE  EVALUATION  OF  A  RELATIONAL..  ASSOCIATIVE 
PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [ACM  Transactions  on  Database 
Systems,  v.  1,  n:4,  December  1976] 

EDITING  COMPUTER  ANIMATED  FII.M 
Michael  D.  Tilaon,  February  1976 
[M.Sc.  Thesis.  DCS,  1975] 


A  DIAGRAMMATIC  APPROACH  TO  PROGR/KMMING  LANGUAGE 
SEM.ANTICS 

James  R.  Cordy,  March  1976 
[M.Sc.  Thesis.  DCS,  1976] 

A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A  RELATIONAL 
ASSOCIATIVE  PROCESSOR 

L.  Kerschberg,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco, 

April  1976 

AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTFR  PROGRAM 
ENGINEERING 

D.  Barnard  and  D.  Thompson  (eds.).  Fourth  Edition, 

May  1976 


A  T.AXONOMY  OF  DATA  MODELS 

L.  Kerschberg.  A.  Kiug.  and  D.Tslchritzis,  .May  19/6 
[Proceedings  Very  Large)  Data  Base  Coiifcr'cm.-c,  1976] 


OPTIMIZATION  FEATURES  FOR  ‘J'HE  ARCHlTEClTiRE  OF  A 


DATA  BASE  MACHINE 

E.A.  Ozkax'ahan  and  K.C.  Sevcik,  .May  197G 

[ACM  Transactions  of  Database  Sy'stems,  v.2,  n.4,  December  1977] 


THE  RELATIONAL  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 
H.A.  Schmid  (ed.).  L'.A.  Bern.slcin  (ed.),  11,  Arlow, 

R.  Bailor  and  S.  lk)/.g(ij,  .luly  1976 
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■=•  CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
PFLATIONAL  DATA  PASF  SOU  KWAS 
P.A.  Berniilein  and  C.  Beeri,  Sepl.ember  1970 


CSRG-74  A  HIGH-LEVEL  MACHINE-ORIENTED  ASSEMBLER  HHNGUAGE 
FOR  A  DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  S.A.  Schuster,  October  1976 


CSRO-75  DO  CONSIDERED  QD:  A  CONTRIBUTION  TO  THE  PROGRAMMING 
C/JLCULUS 

Eric  C.R.  Hehner,  November  1976 
Acta  Informatica  to  appear  1979 


CSRG-76  SOFTWARE  HUT:  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Plorning  and  D.B.  'uortman,  November  1976 

[IEEE  Transactions  on  Scft’.varc  Engineering,  v.SE-3,  n.4,  July  1977] 


CSRG-77 


A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOUR 
G.  Scott  Graham,  January  1977 


■='  CSRG-78  A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichritzis  (ed.),  Febi’uary  1977 


CSRG-79  THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LALR 
PARSE  TABLE  CONSTRUCTOR 
David  H.  Thompson,  April  1977 
[M.Sc/Thesis,  DCS,  1976] 


CSRG-80  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  FROGRA-M 
ENGINEERING 

D.  Barnard  (ed.),  Fifth  Edition,  May  1977 


CSRG-81  PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  BIBLIOGRAPHY 
FOR  IFIP  WORKING  CROUP  2.3 

Sol  J.  Greenspan  and  J.J.  Horning  (eds.).  First  Edition.  May  1977 
CSRG-B2  NOTES  ON  EUCLID 

edited  by  W.  David  Elliott  and  David  T.  Barnard.  August  1977 


CSRG-63  TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 


CSRG-84  TOWARD  PROGRAM  ILLUSTRATION 

Edi^ard  Yaiavood,  September  1977 
[M.Sc.  Thesis,  DCS.  1974] 


CSRG-B5 


CMAItACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME 

DISTRIBUTIONS  IN  QUEUEING  NETWOI^K  MODEL.S  OF  COMPUTER 
SYSl’EMS 


Ed’-vf\rd  D.  La/owska,  Sciol  r’lehcr’  1977 
[Ph.D.  Thesis.  DCS.  1977] 
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CSRC-OO 

MEASUREMENTS  OF  COMPUTER  SYSTEMS  FOR  QUEUEING 

NETWOliK  MODELS 

Martin  G.  Kienzle,  October  1977 

[M.Sc.  Thesis,  DCS,  1977;  Proc.  Int.  Syrrip.  on  Modelling  and  Performance 
Evaluation  of  Computer  Systems,  Vienna,  1979] 

CSRG-a? 

’OLGA’  LANGUAGE  REFERENCE  MANUAL 

B.  Abourbih,  H,  Trickey,  D.M.  Lewis.  E.S.  Lee, 

P.I.P.  Boulton.  November  1977 

*  CSRG-93  USING  A  GRAMMATICAL  F0R.MAL1SM  AS  A  PROGRAMMING  LANGUAGE 
Brad  A.  SLlverberg,  January  1970 


[M.Sc.  Thesis,  DCS.  1978] 

CSRG-89 

ON  THE  IMPLEMENTATION  OF  RELATIONS;  A  KEY  TO  EFFICIENCY 

Joachim  W.  Schmidt,  January  1978 

CSRG-90 

DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 

Frederick  H.  Lochovsky,  April  1973 
[Ph.D.  Thesis.  DCS.  1978] 

C3RG-9 1 

SPECIFICATION  AND  VERIFICATION  OF  DATA  BASE 

SEMANTIC  INTEGRITY 

Michael  La'^^’Tence  Brodie,  April  1973 
[Ph.D.  Thesis.  DCS.  1978] 

CSRG-92 

STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP): 

AN  INTRODUCTION 

by  William  Buxton,  Guy  Fedorkovr,  with  Ronald  Bacckcr, 

Gustav  Ciamaga,  Leslie  Mezei  and  K.C.  Smith.  June  1973 

*  CSRG-93  ADEVICE-INDEPENDENT.GENERAL-PURPOSE  GRAPHICS  SYSTEM 


IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 

Vrilliam  T.  Reeves.  August  1978 
[M.Sc,  Thesis,  DCS,  1976] 

CSRG-94 

ON  THE  .MXIOMATIC  VERIFICATION  OF 

CO N CU RRENT  ALG  0 RI TK  M S 

Christian  Lengauer.  .August  1978 
[M.Sc.  Thesis,  DCS.  1973] 

CSRG-95 

PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 

PRODUCTION  OF  APPLIC.ATION  SOFTWAIUI 

Rudolf  Marty,  August  197B 

CSRC-96  AD/J'TIVE  MICROPROGI^MING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 


CSRG-97 

[Ph.D.  Thesis.  EE.  August  1978] 

DESIGN  ISSUES  IN  THE  FOUNDATJON  OF  A  COMPU  I'ER-BASED 

TOOL  FOR  MUSIC  COMPOSITION 

Willinrr,i  Buxton 

[M.Sc.  Thesis,  eSRG,  October  HLUJl 

CSRG-97 
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CSRG-9B  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  King 

[Ph.D.  Thesis,  DCS,  December  1973] 

CSRG-99  HIER.\RCH]C.\L  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  1.  Vanek,  Februar}'  1979 

CSRG-lUO  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 

CSRG-101  A  PAUIACHE  OF  DBMS  IDEAS  11 

F.H.  I.Dchovsky  (ed.),  May  1979 

CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.R.  Hehner,  May  1979 

CSRG-i03  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Cheng 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MiNLLANGUAGE 
D.  Hugh  Redelmeiei ,  July  1979 

CSRG-105  A  LANGUAGE  FACILITY  FOR  DESIGNING  INTEI^CTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos,  Philip  A_  Bernstein,  Harr}''  K.T.  Yiong, 
July  1979 


;SRG-1G6  ON  APPROXIMATE  SOLUTION  TECHNIQUES  FOR 

QUEUEING  NETWORK  MODEL, S  OF  COMPUTER  SYSTEMS 
Satish  Kumar  Tripathi,  July  1979 


C3RG-107  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  K.  Tsotsos,  John  Mylopoulos,  H.  Dominic  Co\n^ey 
Steven  W.  Zucker,  DCS,  June  1979 

CSRG-lOB  DIAL.OGUE  ORGANIZATION  AND  STRUCTURE  FOR 
INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thesis,  DCS,  1960] 

"  CSRG-109  A  UNIFYING  MODEL  OF  PHYSICAL  DATAHASFS 
D.S.  Dalory,  C.C.  Gotiieb,  April  1900 

''  CSRG-110  OPTIMAL  FILE  DESIGNS  AND  REORGANIZATION  POINTS 
D.S.  Batory,  April  19B0 

^  CSRG-111  A  PANACHE  OF  DBMS  IDEAS  III 
D.  Tsichritzi.s  (cd.),  April  L9B0 
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CSRG-112  TOPICS  IN  PSN  -  II:  EXCEPTIONAL  CONDITION 


HANDLING  IN  PSN;  REPRESENTING  PROGRAMS  IN  PSN; 
CONTENTS  IN  PSN 

Yves  Lespei'ance,  Byran  M.  Krairier,  Piiler  !•'.  Seluieider 
April,  1980 


CSRG-113  SYSTEM-ORIENTED  MACRO-SCHEDULING 
C,C.  Gotlieb  and  A.  Schonbach 
May  1980 

CSRG-1 14  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  Konstantine  Tl'oIsos 
[Ph.D.  Thesis.  DCS,  June  1980] 

CSRG-llS  SPECIFICATION  OF  CONCURRENT  EUCLID 
James  R.  Cordy  and  Richard  C.  Holt 
July  1980 


CSRG-H6  THE  REPRESENTATION  OF  PROGRAMS  IN  THE 

PROCEDURAL  SEMANTIC  NETWORK  FORM.VLISM 

Bryan  M.  Kramer 

[M.Sc.  Thesis.  DCS.  1980] 


CSRG-1 17  CONTEXT-FREE  GRAMMARS  AND  DERIVATION  TREES  AS 
PROGRAMMING  TOOLS 
Volker  Linnemann 
September  1930 


CSRG-1 18  S/SL;  SYNT‘\X/SEIvL'MNTiC  L/VNGUAGE 
INTRODUCTION  AND  SPECIFICATION 


R.C.  Holt,  J.R.  Cordy,  D.D.  Wortman 
CSRG,  September  1980 


CSRG-1 19  PT;  A  PASCAL  SUBSET 
Alan  Rosselet 

[M.So.  Thesis,  DCS,  October  1980] 

CSRG-120  PTED:  A  STANDARD  PASCAL  TEXT  EDITOR  BASED  ON 
THE  KERNIGHAN  AND  PLAUGER  DESIGN 
Ken  Netvman,  DCS 
October  1900 


CSRG- 121  TERMINAL  CONTEXT  GRAMMARS 
Howard  W.  Trickey 
[M.Sc.  Thesis,  EE,  Seplcniber  iSBO] 

CSRG-122  THE  APPROXIMATE  SOLUTION  OF  LARGE  QUEUEING 
NETWORK  MODELS 
John  Zahorjan 

[Ph.D.  Thesis,  DCS,  August  1980] 
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CSRG-123  A  FQRM.\L  TREATMENT  OF  IMPERFECT  INI’ OI^MATIO.N 
IN  DATABASE  MANAGEMENT 
Yannis  Vassiliou 

[Ph.D.  Ihesis,  DCS,  September  1980] 

CSRG-i24  ANALYTIC  MODEL  01"  PHYSICAL  DAl'.ABASES 
Don  S.  Batory 

[Ph.U.  Thesis,  DCS,  January  1981] 

CSRG-125  MACHINE-INDEPENDENT  CODE  GENERATION 
Richard  H.  Kozlak 
[M.Sc.  Thesis,  DCS.  January  1991] 

CSRG-126  COAiPUTER  MACKU-SCHEDULINC  FOR  HIGH  PRODUCTIVTIT 
Abraham  Schnnbach 
[Ph.D.  Thesis,  DCS.  .March  1981] 

CSRG-127  OMEGA  ALPHA 

D.  Tsichrilzis  (ed.),  March  1931 

CSRG-123  DIALOGUE  AND  PROCESS  DESIGN  FOR  INTERACTIVE 
INFORMATION  SYSTEMS  USING  TAXIS 
John  Barron,  April  1981 

CSRG-129  DESIGN  AND  VERIFICATION  OF  INTERACTIVE  INFORMATION 
SYSTEMS  USING  RMXIS 
Harry  K.T.  Wong 

[I’h.D.  Thesis,  DCS,  to  be  subnaitt'-'cl] 


